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

The default BSP is compiled based on the Yocto project, which is a streamlined production-level Linux BSP. However, for users who are accustomed to the Ubuntu environment, especially ROS users, the operation of Yocto will be relatively complicated. This article will introduce how to make an Ubuntu BSP for iMX8QM and demonstrate how to use ROS.   A complete Ubuntu BSP includes u-boot, Linux kernel and Ubuntu rootfs. We will use u-boot and Linux kernel in Yocto BSP official 6.1V BSP, and rootfs will still use ubuntu-base-18.04.4-base-arm64. The compilation method comes from the NXP forum. First download ubuntu-base-18.04.4-base-arm64.tar.gz from the link above, and then unzip it. $ mkdir ~/ubuntu-rootfs $ sudo tar vxf ubuntu-base-18.04.4-base-arm64.tar.gz -C ubuntu-rootfs Copy the script file and create ch-mount.sh. $ sudo chmod a+x ./ch-mount.sh The download above is a basic Ubuntu-base file system, which is missing many commonly used tools and requires us to install it. For this purpose, install the qemu-user-static software on your computer to simulate the arm64 operating environment. $ sudo apt install qemu-user-static Mount the Ubuntu-base file system and then operate directly in the arm64 environment. $ sudo ./ch-mount.sh -m ubuntu-rootfs/ Add a DNS server, such as 8.8.8.8, or other available DNS server IP. # echo nameserver 8.8.8.8 > /etc/resolv.conf Install relevant software, of course you can also add other software. # apt install language-pack-en-base sudo ssh net-tools \ network-manager iputils-ping rsyslog \ bash-completion htop resolvconf dialog \ vim nano v4l-utils alsa-utils git gcc \ less resolvconf autoconf autopoint libtool \ bison flex gtk-doc-tools glib-2.0 \ libglib2.0-dev libpango1.0-dev libatk1.0-dev kmod pciutils -y  Create a user and set a password, here the user name is ubuntu # useradd -s '/bin/bash' -m -G adm,sudo ubuntu # passwd ubuntu # passwd root # echo 'apalis-imx8' > /etc/hostname At this point basic Ubuntu has been configured. # exit $ sudo ./ch-mount.sh -u ubuntu-rootfs/  After the installation is complete, use the ubuntu user to log in to the debugging serial port, and the password is ubuntu. When starting for the first time after installation, it will wait for a long time due to initialization, and then enter the configuration interface including region, user settings, etc. Turn on Ethernet and set DNS server IP.  ubuntu@mx8QM:~$ sudo ifconfig eth0 up ubuntu@mx8QM:~$ sudo dhclient eth0 ubuntu@mx8QM:~$ sudo vi /etc/resolv.conf Start Weston: ubuntu@mx8QM:~$ export XDG_RUNTIME_DIR=/run/user/1000 ubuntu@mx8QM:~$ sudo -E weston --tty=1 & ubuntu@mx8QM:~$ weston-flower ROS test You can install ROS programs very conveniently in Ubuntu system. Please refer to the instructions below for details http://wiki.ros.org/melodic/Installation/Ubuntu http://wiki.ros.org/ROS/Tutorials ubuntu@mx8QM:~$ sudo apt install lsb-core ubuntu@mx8QM:~$ sudo sh -c 'echo "deb http://packages.ros.org/ros/ubuntu $(lsb_release -sc) main" > /etc/apt/sources.list.d/ros-latest.list' ubuntu@mx8QM:~$ sudo apt-key adv --keyserver 'hkp://keyserver.ubuntu.com:80' --recv-key C1CF6E31E6BADE8868B172B4F42ED6FBAB17C654 ubuntu@mx8QM:~$ sudo apt update ubuntu@mx8QM:~$ sudo apt install ros-melodic-desktop  Run the following commands on three SSH terminals to simulate communication between ROS nodes. ubuntu@mx8QM:~$ source /opt/ros/melodic/setup.sh ubuntu@mx8QM:~$ roscore ubuntu@mx8QM:~$ source /opt/ros/melodic/setup.sh ubuntu@mx8QM:~$ rosrun roscpp_tutorials talker ubuntu@mx8QM:~$ source /opt/ros/melodic/setup.sh ubuntu@mx8QM:~$ rosrun roscpp_tutorials listener Due to driver limitations, iMX8 does not support Xorg, so ROS's default graphical interface tools such as rqt cannot be used directly.        

On behalf of Gopise Yuan. In case some customer may make mistake in mechanical design, they may need to flip/mirror the screen. DPR in DPU can do this in a simple way. This patch demonstrate how to enable VFLIP and HFLIP in DPR to do a V+H flip (=180 rotate) of the screen

The attached document describes how to integrate the souphttpsrc plugin and make it work.

       

Hi all, I'm using this patch to get BT656 output on my i.MX6Q: Patch to Support BT656 and BT1120 Output For i.MX6 BSP Now I am looking for a way to clamp the pixel values between 16 to 240. Based on the i.MX6Q Reference Manual (37.4.5.6 IC Task Parameter Memory), this can be done by setting a IC task parameter called SAT_MODE from 0 to 1, but I'm not sure how it should be done. I've inspected the ipu_disp.c code and I guess the right way to do this is calling ipu_dp_write inside __ipu_dp_csc_setup function to set SAT_MODE to 1, but know I don't know which address to give toipu_dp_write since SAT_MODE is not defined in the ipu_regs.h. Looking at other parameters addresses (e.g. DP_CSC_0) and comparing their counterpart in the Reference Manual doesn't get my anywhere either. Bests, Isaac Hi Isaac, the default BSP code doesn't support DP_CSC_YUV_SAT_MODE modification, just used the default value 0. You can reference to the ioctl "MXCFB_SET_GAMMA" to add it into mxcfb_ioctl() of file mxc_ipuv3_fb.c. Bit 11 in IPUx_DP_COM_CONF_SYNC is for DP_CSC_YUV_SAT_MODE. So you can add it in ipu_regs.h: DP_COM_CONF_CSC_DEF_BOTH = 0x00000100, + DP_COM_CONF_CSC_YUV_SAT_MODE = 0x00000800, DP_COM_CONF_GAMMA_EN = 0x00001000, For BT656 display, IC CSC was not used, it used DP CSC. This document was generated from the following discussion: How to change SAT_MODE in BT656 display output for i.MX6

  Some customers are using sgtl5000 in android. So i generate this patch of sgtl5000 in Android11(i.MX8QM)

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-343576 

D1 Capture - kernel 2.6.22 diff --exclude CVS -uNr linux-2.6.22/include/asm-arm/arch-mxc/memory.h linux-2.6.22.modified/include/asm-arm/arch-mxc/memory.h --- linux-2.6.22/include/asm-arm/arch-mxc/memory.h     2009-07-16 16:29:45.000000000 -0300 +++ linux-2.6.22.modified/include/asm-arm/arch-mxc/memory.h     2009-07-15 15:38:34.000000000 -0300 @@ -28,6 +28,7 @@     /* Size of contiguous memory for DMA and other h/w blocks */     #define CONSISTENT_DMA_SIZE     SZ_16M    +     /*!      * @defgroup Memory_MX27 Memory Map      * @ingroup MSL_MX27 @@ -48,7 +49,7 @@     #ifdef CONFIG_DMA_ZONE_SIZE     #define MXC_DMA_ZONE_SIZE     ((CONFIG_DMA_ZONE_SIZE * SZ_1M) >> PAGE_SHIFT)     #else    -#define MXC_DMA_ZONE_SIZE     ((12 * SZ_1M) >> PAGE_SHIFT)   +#define MXC_DMA_ZONE_SIZE     ((20 * SZ_1M) >> PAGE_SHIFT)     #endif      static inline void __arch_adjust_zones(int node, unsigned long *zone_size, diff --exclude CVS -uNr linux-2.6.22/drivers/media/video/mxc/capture/mxc_v4l2_capture.c linux-2.6.22.modified/drivers/media/video/mxc/capture/mxc_v4l2_capture.c ---    linux-2.6.22/drivers/media/video/mxc/capture/mxc_v4l2_capture.c     2009-07-16 16:29:43.000000000 -0300 +++ linux-2.6.22.modified/drivers/media/video/mxc/capture/mxc_v4l2_capture.c     2009-07-16 16:08:02.000000000 -0300 @@ -1650,9 +1650,9 @@                  /* setup cropping */                 cam->crop_bounds.left = 0; -             cam->crop_bounds.width = 640; +             cam->crop_bounds.width = 800;                 cam->crop_bounds.top = 0; -             cam->crop_bounds.height = 480; +             cam->crop_bounds.height = 600;                 cam->crop_current = cam->crop_defrect = cam->crop_bounds;                 ipu_csi_set_window_size(cam->crop_current.width,                                                       cam->crop_current.height); @@ -1663,7 +1663,7 @@                 cam->standard.id = V4L2_STD_UNKNOWN;                 cam->standard.frameperiod.denominator = 30;                 cam->standard.frameperiod.numerator = 1; -             cam->standard.framelines = 480; +             cam->standard.framelines = 600;                 cam->streamparm.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;                 cam->streamparm.parm.capture.timeperframe =                 cam->standard.frameperiod; cam->streamparm.parm.capture.capability = V4L2_CAP_TIMEPERFRAME; diff --exclude CVS -uNr linux-2.6.22/drivers/media/video/mxc/capture/ov2640.c linux-2.6.22.modified/drivers/media/video/mxc/capture/ov2640.c ---    linux-2.6.22/drivers/media/video/mxc/capture/ov2640.c     2009-07-16 16:29:45.000000000 -0300 +++ linux-2.6.22.modified/drivers/media/video/mxc/capture/ov2640.c     2009-07-16 16:07:03.000000000 -0300 @@ -698,12 +698,12 @@     #endif                            g_cam->streamparm.parm.capture.capturemode = 1;                 } else { -          out_width = 640; -          out_height = 480; +          out_width = 800; +          out_height = 600;                 g_cam->crop_bounds.left = 0; -          g_cam->crop_bounds.width = 640; +          g_cam->crop_bounds.width = 800;                 g_cam->crop_bounds.top = 0; -          g_cam->crop_bounds.height = 480; +          g_cam->crop_bounds.height = 600;                 g_cam->crop_current = g_cam->crop_defrect = g_cam->crop_bounds;     #ifdef CONFIG_ARCH_MX3                              ipu_csi_set_window_size(g_cam->crop_current.width ,

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-343102 

Building on the success of low-cost, high-performance application development kits, Freescale introduces the i.MX27 Lite Kit. Once again, Developed in Logic Product Development and Freescale have worked together to deliver a product-ready software and hardware platform for OEMs, ODMs, IDHs and independent developers and a price point that's quite appealing. The i.MX27 Lite Kit enables rapid design of embedded products targeting the medical, industrial, wireless, consumer markets and general purpose markets. Leverage the power of the i.MX27 multimedia processor in this cost-effective development solution. Features The Freescale i.MX27 SOM-LV is based on the i.MX27 multimedia applications processor running up to 400 MHz. Click here for the full list of i.MX27 SoC features: Includes i.MX27 SOM-LV module Standard peripheral connectors supporting: Ethernet, LCD, audio in/out, serial, CompactFlash®, MMC/SD, USB host, USB OTG, ATA LogicLoader™ (bootloader/monitor) in executable format GNU Cross-Development Toolchain (compiler, linker, assembler, debugger) included Kit contents: i.MX27 SOM-LV Application baseboard Expansion header breakout board Null-modem serial cable Ethernet crossover cable USB A to mini-B cable 5 volt power supply with power adapters (Europe, Japan, UK, and US) Logic Starter CD QuickStart Guide Zoom™ LV baseboard (146.1 x 158.8 x 17.1 mm) RoHS compliant

Attached slides introduce the i.MX95 Power management with following topics: SoC Power Architecture Power Management with BSP Power on/off & Reboot Suspend Implementation Low Power Run

The purpose of this document is to provide extended guidance for selection of compatible LPDDR4 memory devices that are supported by the Ara240 (aka Ara-2) processors. In all cases, it is strongly recommended to follow the DRAM layout guidelines outlined in the specific SoC requirement documents. LPDDR4 - maximum supported densities SoC Max Data bus width Maximum density Number of Interfaces Assumed memory organization Notes Ara240 64-bit 128Gb/16GB 2 Dual rank, Dual channel device with 17-row addresses 1   LPDDR4 - list of validated memories The validation process is an ongoing effort - regular updates of the table are expected. SoC Density Memory Vendor Validated Memory Part# Notes Ara240 64Gb/(8GB) Total 128Gb/(16GB) (2 x 64Gb/8GB) Micron   MT53E2G32D4DE-046 AUT:C  MT53E2G32D4DE-046 WT:C - 64Gb/(8GB) Total 128Gb/(16GB) (2 x 64Gb/8GB)   FORESEE FLXC4008G-30  2 16Gb/(2GB) Total: 32Gb/(4GB) (2 x 16Gb/2GB) Micron MT53E512M32D1ZW-046BAUT:B     - 32Gb/(4GB) Total 64Gb/8GB (2 x 32Gb/4GB)   Micron MT53E1G32D2NP-046 WT:B - 16Gb/(2GB) Total: 32Gb/(4GB) (2 x 16Gb/2GB) SK Hynix H54G46CYRQX053N - 32Gb/(4GB) Total 64Gb/8GB (2 x 32Gb/4GB) SK Hynix H54G56CYRB-X247 421Y H54G56CYRB-X247 316A - 4Gb/(512MB) Total 8Gb/1GB (2 x 4Gb/1GB) SK Hynix H54G26AYRBX256 - 16Gb/(2GB) Total: 32Gb/(4GB) (2 x 16Gb/2GB) Samsung K4F6E3S4HB-KHCL      - 32Gb/(4GB) Total 64Gb/8GB (2 x 32Gb/4GB) ISSI IS43LQ32K01B 2 32Gb/(4GB) Total 64Gb/8GB (2 x 32Gb/4GB) Samsung K4UBE3D4AB-MGCL - 8Gb/(1GB) Total 16Gb/2GB (2 x 8Gb/1GB)   Winbond W66DP2RQQAHJ 2   Note: This device supports operation with LPDDR4 memories only. LPDDR4x operation is not supported. Dual‑mode memories that support both LPDDR4 and LPDDR4x are allowed as long as the device can operate in LPDDR4 mode, including using LPDDR4 I/O voltage levels and initialization sequences.   Note 1: The numbers are based purely on the IP documentation for the DDR Controller and the DDR PHY, on the settings of the implementation parameters chosen for their integration into the SoC, SoC reference manual and on the JEDEC standards JESD209-4C (LPDDR4). Therefore, they are not backed by validation, unless said otherwise and there is no guarantee that an SoC with the specific density and/or desired internal organization is offered by the memory vendors. Should the customers choose to use the maximum density and assume it in the intended use case, they do it at their own risk. Note 2: The memory part number did not undergo full JEDEC verification however, it passed all functional testing items. Note 3: Memory devices with binary densities (e.g., 1 GB, 2 GB, 4 GB) are preferred because they simplify memory management by aligning with system addressing schemes and reducing software complexity. Note 4: All memory parts are in production unless stated otherwise. Checked June 2026 Note 5: The processor does not support BYTE Mode (x8) memories.       

Overview The purpose of this document is to provide guidance for FlexIO 8080 display capability. Generally, the 8080 bus interface consists of one chip-select line (CS), one writing-latch line (WR), one reading-latch line (RD), one data/command-select line (RS, also called D/C), and 8 or 16 bidirectional data lines (Data Bus). Since The FlexIO instance of i.MX 943 support only 16 pins, the demo can only support 8 bit 8080 mode(two pin should be used as WR and RD signal.   Below are pins used in the 8 bit 8080 display. Panel Setup The panel in the example is X-LCD-PAR-S035. To use 8 bit 8080 mode, need ser IM[2:0] to be 011. Connection and Software i.MX 943 Need pull down SPI8_SEL1 and SPI8_SEL3 of PCA6416 in SW to select Arduino for 8080 pins D[7:4]. Here is the patch for system manager. For quick verification, use flash_m70 when building bootloader. diff --git a/configs/mx94evk.cfg b/configs/mx94evk.cfg index 9d46976..90bf089 100755 --- a/configs/mx94evk.cfg +++ b/configs/mx94evk.cfg @@ -499,6 +499,9 @@ ENC_PLL OWNER ENDAT2_1 OWNER ENDAT2_2 OWNER ENDAT3_1 OWNER +GPIO2 OWNER +GPIO3 OWNER +FLEXIO1 OWNER FLEXIO3 OWNER FLEXIO4 OWNER FLEXPWM1 OWNER @@ -515,6 +518,7 @@ HIPERFACE_SAFE1_2 OWNER HIPERFACE_SAFE2_1 OWNER HIPERFACE_SAFE2_2 OWNER IRQSTEER_M7_0 OWNER +LPI2C6 OWNER LPIT1 OWNER LPTMR1 OWNER LPTMR2 OWNER @@ -557,6 +561,25 @@ XBAR_DSC3 OWNER PIN_GPIO_IO24 OWNER PIN_GPIO_IO25 OWNER +# 8080 +PIN_GPIO_IO00 OWNER +PIN_GPIO_IO01 OWNER +PIN_GPIO_IO02 OWNER +PIN_GPIO_IO03 OWNER +PIN_GPIO_IO08 OWNER +PIN_GPIO_IO09 OWNER +PIN_GPIO_IO10 OWNER +PIN_GPIO_IO11 OWNER +PIN_GPIO_IO12 OWNER +PIN_GPIO_IO13 OWNER +PIN_GPIO_IO14 OWNER +PIN_GPIO_IO15 OWNER +PIN_GPIO_IO38 OWNER + +# I2C6 +PIN_GPIO_IO28 OWNER   Attached imx943_flexio_8080_8bit.zip is patch for m70 demo based on SDK_25_06_00_MCIMX943-EVK.   i.MX 93 Need pull up EXP_SEL(pin4 R4) of ADP5585 in SW to route some pins. Attached imx93_flexio_8080_8bit.zip is patch for m33 demo based on SDK_25_06_00_MCIMX93-EVK. The running status is similar as i.MX943.

 

    Test envs: BOARD: i.MX 8MN EVK BSP: L6.6.36   The L6.6.y includes the feature about supporting starting Cortex-M33 from non-TCM address for i.MX93, but not for i.MX8M series.    LF-7815 remoteproc: imx_rproc: support starting Cortex-M33 from non-TCM address for i.MX93 https://github.com/nxp-imx/linux-imx/commit/680aa11c7bdaddf6bbffd74bc0a94ef67593b69b#diff-66a34e17e82d281936f559217adc3983b39abeb2e478967f3d5cef2eed5b67fcR693   For older BSP, customer can refer this full patch set https://patchew.org/linux/[email protected]/   If you want to test ELF in DDR on i.MX8M series and i.MX93 platform with L6.6.y, please use below patch set.  

share more detailed steps how to bring up stereo capture of basler camera by imx8mp

  Solution           

The IOMUX module on i.MX 8M enables flexible I/O multiplexing, allowing users to configure each IO pad as one of selectable functions. The CSU (Central Security Unit) module on i.MX 8M can be used to configure some devices as secure only accessible to protect the security of these devices. But as the IOMUX is Non-Secure accessilbe and thus the pad function can be configured dynamicaly, there is one risk if hackers reconfigure the IO pad to make the device connected to other controller which is accessible to Non-Secure world. One solution for this issue is configuring the CSU to limit Non-Secure access to IOMUX, all IOMUX registers write operations are routed to Trusty OS. In the Trusty OS, add all sensitive IO resources to one blacklist, the IOMUX driver in Trusty OS should check and deny any write attemption to sensitive registers from Non-Secure world. One example patch set is attached to show how to assign the IOMUX to secure world and how to route the IOMUX write operations to Trusty OS. In this example, the USB Host pinctrl PAD on i.MX8MP EVK was assigned to secure world. The layout of the example codes are:     . ├── atf │ └── 0001-config-iomux-to-secure-write.patch --> ${MY_ANDROID}/vendor/nxp-opensource/arm-trusted-firmware ├── kernel │ └── 0001-Use-Trusty-OS-to-handle-iomux-registers-written-oper.patch --> ${MY_ANDROID}/vendor/nxp-opensource/kernel_imx/ ├── trusty │ └── 0001-Add-iomux-pinctrl-TEE-handler.patch --> ${MY_TRUSTY}/trusty/hardware/nxp └── u-boot └── 0001-Use-Trusty-OS-to-handle-IOMUX-operation.patch --> ${MY_ANDROID}/vendor/nxp-opensource/uboot-imx      

Following OTA in Android User Guide would have HASH verification error: update_engine: [0913/085233.421711:ERROR:delta_performer.cc(1140)] Expected: sha256|hex = 685B998E4308F20FEA83D97E60222121FFE27983F013AED5C203709E139AE9DB update_engine: [0913/085233.421760:ERROR:delta_performer.cc(1143)] Calculated: sha256|hex = B1025634138BF2B5378196E364350E1E5FCA126DEE0990A592290CEBFADC3F8B The OTA process that produced the error: * After compiling the images according to the user guide, burn the images in the /out directory into the board * Then build the first target file according to 7.1.1 Building target files, such as PREVIOUS-target_files.zip * Modify part of the code to build the second target file, such as NEW-target_files.zip: * Make a differential upgrade package and perform differential OTA The root cause of the error caused by the above steps: Differential OTA requires that the onboard system.img must be the system.img generated when the target files are created for the first time. Only in this way can the correct hash value be calculated. When we execute the following command to make target files make target-files-package -j4 Will repackage a copy of system.img in the /out directory and this system.img does not meet the requirements. The system.img used by the differential package must be system.img in out/target/product/evk_8mm/obj/PACKAGING/systemimage_intermediates/. Therefore, the system.img we burned in the first step did not meet the requirements, resulting in hash verification errors. Solution 1: After the first step of programming, do a full update. When using the make otapackage -j4 command, a target_files.zip file will also be generated, which we will regard as PREVIOUS-target_files.zip. Modify part of the code and make NEW-target_files.zip. Finally, the differential upgrade can be successful. Solution 2: After finishing the first target_files.zip, copy the system.img in out/target/product/evk_8mm/obj/PACKAGING/systemimage_intermediates/ to the out/target/product/evk_8mm directory, and then use uuu Perform programming. After burning and writing, make the second target_files.zip, and finally you can upgrade by differential.