Description       This doc explain how to enable the plugin boot on i.MX6Q/6DL and which used for change the pll2 clock and add the spread spectrum support to pass the EMI test. we still list the source codes of 3.0.35 and 4.1.15. to explain the dts/non-dts kernel support.       本文旨在说明如何在i.MX6Q/6DL上实现plugin启动，以支持展频和改变pll2的频率，其目的是为了通过 EMI测试。也附上了基于3.0.35和4.1.15的源代码，以供参考   Products Product Category NXP Part Number URL MPU i.MX6 Family https://www.nxp.com/products/processors-and-microcontrollers/arm-processors/i-mx-applications-processors/i-mx-6-processors:IMX6X_SERIES   Tools NXP Development Board URL i.MX6 SabreSDP https://www.nxp.com/design/development-boards:EVDEBRDSSYS#/collection=softwaretools&start=0&max=25&query=typeTax%3E%3Et633::archived%3E%3E0::Sub_Asset_Type%3E%3ETSP::deviceTax%3E%3Ec731_c380_c127_c126&sorting=Buy%2FSpecifications.desc&language=en&siblings=false          Version: MX6Q_PLUGIN_FC_SSC_V7-20200915_chn..pdf（chinese version）add baidou support MX6Q_PLUGIN_FC_SSC_V7-20170504_eng-chapter-imx6dl.doc+MX6Q_PLUGIN_FC_SSC_V3-20170309_eng.doc（english version）      

gst-launch is the tool to execute GStreamer pipelines. Task Pipeline Looking at caps gst-launch -v  <gst elements> Enable log gst-launch --gst-debug=<element>:<level> gst-launch --gst-debug=videotestsrc:5 videotestsrc ! filesink location=/dev/null

tarball created by Curtis Wald and Leonardo Sandoval containing patches to fix ltib issues for Ubuntu 12.04.   Steps to use this tarball   # go to ltib folder $ cd <ltib full path>   # untar the tarball $ tar -xzvf ubuntu-ltib-patch.tgz   # go to untared folder $ cd ubuntu-ltib-patch   #install patches $ ./install-patches.sh <ltib full path>     You above steps are contained in this script:   https://community.freescale.com/servlet/JiveServlet/downloadBody/93455-102-2-2825/patch-ltib-ubuntu12.04.sh,   so instead of typing them manually you can execute the following command   curl -L https://community.freescale.com/servlet/JiveServlet/downloadBody/93455-102-2-2825/patch-ltib-ubuntu12.04.sh | bash   under your ltib folder.

Most common issues with bringup and memory stability come down to memory/system setup during startup phase of i.MX device.   This Python script allows you to dump IVT/DCD tables and data from a i.MX binary (either generated as result of build process or a simple dump of SD/NOR/NAND... content) and analyze them in an easier way. Should work with i.MX 6 and i.MX53 binaries.   Parser for i.MX 6 will also try to print out register values it recognizes, and also parse specific register fields, helping to analyze the data faster. This can be extended if needed to other registers/values.   imxbin.py works with Python3.x and imxbin_2x.py with Python 2.x, so choose appropriate version.   Vladan

i.mx8M evk board has HW decoder and SW encoder, this document introduce how to use HW decoder and SW encoder the bsp is the latest version L4.14.78, the environment is : $ DISTRO=fsl-imx-wayland MACHINE=imx8mqevk source fsl-setup-release.sh -b build-wayland $ bitbake fsl-image-validation-imx   For the 4.14.78, we don’t use mfgtool anymore, customer can use uuu.exe to program the image to the board, the uuu.exe can be found from https://github.com/NXPmicro/mfgtools/releases Here we use emmc as media, I attached the kerel_emmc.uuu for reference Open the cmd.exe, then use the command “uuu.exe kernel_emmc.uuu” to download the image to the emmc on the board as the picture shows When the board boot up, don’t forget to change the image and fdt_file as you want, for example, I use Image-imx8mqevk.bin as image name  and Image-fsl-imx8mq-evk.dtb as my fdt file, you can choose different image and fdt file as uuu file mentions. 1) Decoding   For play the video, we can use three solution to support this a) gplay-1.0 test.mp4 b) gst-launch-1.0 playbin uri=file:///mnt/sdcard/test.mp4 c) gst-launch-1.0 filesrc location=test.mp4 typefind=true ! video/quicktime ! aiurdemux ! queue max-size-time=0 ! vpudec ! autovideosink For play the two different video to the different display, current imx8M evk board supports dual hdmi output, in the uboot command: setenv fdt_file Image-fsl-imx8mq-evk-dual-display.dtb saveenv Use the command as below:    gst-launch-1.0 playbin uri=file:///test1.mp4 playbin uri=file:///test2.mp4 video-sink="glimagesink display-master=false display-slave=true" 2) Encoding Because imx8M evk don’t have hardware encoding, so we need to add the SW plugins in the bsp   a)add the commands as below in the /build/conf/local.conf "CORE_IMAGE-EXTRA_INSTALL += "gstreamer1.0-plugins-ugly-meta packagegroup-fsl-gsstreamer1.0-commercial gst-ffmpeg" LICENSE_FLAGS_WHITELIST = "commercial""        b)Create the new txt file and add “PACKAGECONFIG_mx8mq = "x264"”in the file        c)Rename the file as 0-plugins-ugly_%.bbappend and put this file under /sources/meta-fsl-bsp-release/imx/meta-bsp/recipes-multimedia/gstreamer        d)Build the image you want, then download the new rootfs file in the board, use the command “gst-inspect-1.0 | grep x264”

The i.MX Android N7.1.2_2.0.0 GA release is now available on IMX_SW page.   Files available: # Name Description 1 android_N7.1.2_2.0.0_docs.tar.gz i.MX Android N7.1.2_2.0.0 BSP Documentation 2 android_N7.1.2_2.0.0_source.tar.gz Source Code of Android N7.1.2_2.0.0 BSP (4.1 kernel) for i.MX 6QuadPlus, i.MX 6Quad, i.MX 6DualPlus, i.MX 6Dual, i.MX 6DualLite, i.MX 6Solo i.MX 6Sololite, i.MX6SX and i.MX7D 3 android_N7.1.2_2.0.0_image_6dqpsabreauto.tar.gz Binary Demo Files of Android N7.1.2_2.0.0 BSP - SABRE for Automotive Infotainment based on i.MX 6QuadPlus, i.MX 6Quad, and i.MX 6DualLite 4 android_N7.1.2_2.0.0_image_6dqpsabresd.tar.gz Binary Demo Files of Android N7.1.2_2.0.0 BSP - SABRE Platform and SABRE Board based on i.MX 6QuadPlus, i.MX 6Quad and i.MX 6DualLite. 5 android_N7.1.2_2.0.0_image_6slevk.tar.gz Binary Demo Files of Android N7.1.2_2.0.0 BSP - i.MX 6Sololite evaluation kit. 6 android_N7.1.2_2.0.0_image_6sxsabresd.tar.gz Binary Demo Files of Android N7.1.2_2.0.0 BSP - SABRE Board based on i.MX 6SoloX 7 android_N7.1.2_2.0.0_image_6sxsabreauto.tar.gz Binary Demo Files of Android N7.1.2_2.0.0 BSP - SABRE for Automotive infotainment based on i.MX 6SoloX 8 android_N7.1.2_2.0.0_image_7dsabresd.tar.gz Binary Demo Files of Android N7.1.2_2.0.0 BSP - SABRE Board based on i.MX 7Dual 9 fsl_aacp_dec.tar.gz AAC Plus Codec for N7.1.2_2.0.0 10 android_N7.1.2_2.0.0_tools.tar.gz Manufacturing Toolkit and VivanteVTK for N7.1.2_2.0.0   Supported Hardware SoC/Boards: i.MX 6Quad, i.MX 6QuadPlus, and i.MX 6DualLite SABRE-SD board and platform i.MX 6Quad, i.MX 6QuadPlus, and i.MX 6DualLite SABRE-AI board and platform i.MX 6SoloLite EVK platform i.MX 6SoloX SABRE-SD board and platforms i.MX 6SoloX SABRE-AI board and platforms i.MX 7Dual SABRE-SD board and platform   Changes: Compared to the N7.1.1_1.0.0 release, this release has the following major changes: Upgraded the Android code base from android-7.1.1_r13 to android-7.1.2_r9. Upgraded U-Boot from v2015.04 to v2017.03. Upgraded the kernel from v4.1.15 to v4.9.17. Upgraded the GPU driver from 6.2.0.p2 to 6.2.2.p1. Upgraded the Wi-Fi BCMDHD release version to 1.141.100.6. Refine the Gralloc and HWC HAL. Enable the GPT partition to replace the MBR partition.   Feature: For features please consult the release notes.   Known issues For known issues and more details please consult the Release Notes.

Ramdisk is unnecessary thing for some embedded systems, but it's required for Android . You can develop an Android system with no ramdisk (initrd/initramfs), just follow these steps: 1) Remove RAMDISK support from kernel: General setup  --->             [ ] Initial RAM filesystem and RAM disk (initramfs/initrd) support Create a single rootfs: cd myandroid/out/target/product/imx51_BBG mkdir rootfs sudo cp -a system rootfs/ sudo cp -a root/* rootfs/ sudo cp -a recovery rootfs/ Since you are using a single filesystem, then comment out these lines from rootfs/init.rc: #mount ext3 /dev/block/mmcblk0p2 /system #mount ext3 /dev/block/mmcblk0p2 /system ro remount #mount ext3 /dev/block/mmcblk0p5 /data nosuid nodev #mount ext3 /dev/block/mmcblk0p6 /cache nosuid nodev Create just one partition into your MMC or Flash memory: Partition 1: 200MB+ as EXT3 will be used as system(rootfs). Remember to skip 4MB to save kernel. It is a good idea to create a second partition (VFAT) to mount as /data to save user files. Mount that "system" partition and copy all content of rootfs: sudo mount /dev/sdb1 -t ext3 /mnt sudo cp -a .../target/product/imx51_BBG/rootfs/* /mnt sudo umount /mnt Now just setup your bootloader parameter correctly (i.e. MMC Partition 1): setenv bootargs_base 'setenv bootargs root=/dev/mmcblk0p1 rootfstype=ext3 console=ttymxc0,115200 noinitrd'

OK-MX93 SPI2CAN/ADC Release Documentation Overview This document describes how to use the KV11Z SPI2CAN driver to implement IMX93 peripheral interface expansion. The driver connects to the KV11Z microcontroller via SPI interface, extending CAN bus and ADC acquisition capabilities for the IMX93 processor. Key Features: CAN Bus Extension: Provides 1Mbps CAN 2.0A/B communication capability ADC Acquisition Extension: Supports 8-channel 16-bit ADC with 1kHz sampling rate per channel Standard Interface: Fully compatible with Linux CAN Socket API and IIO subsystem High-Performance Transfer: Efficient data transfer architecture based on SPI+DMA+interrupt With this driver, developers can easily implement industrial-grade CAN communication and multi-channel analog signal acquisition on the IMX93 platform. System Architecture System Architecture Diagram Hardware Connection Description IMX93 and KV11Z are connected via standard SPI bus: MOSI: Master Output, Slave Input MISO: Master Input, Slave Output SCLK: SPI clock signal CS: Chip select signal (controlled by GPIO) IRQ: Interrupt signal (KV11Z to IMX93) Important Configuration Notes: Must use GPIO CS + DMA method, main controller CS method has known issues For device tree configuration, refer to the  OK-MX93-C.dts  file in the project SPI frequency recommended to be set at 7-12.5MHz, DMA configuration recommended to be enabled Data Flow Diagram Directory Structure . ├── adctest.c ├── build.sh ├── cantest.c └── OKMX93-linux-kernel-6.1.36 ├── arch │   └── arm64 │   └── boot │   └── dts │   └── freescale │   └── OK-MX93-C.dts └── drivers └── net └── can └── kv11z_spi2can.c Core Components 1. kv11z_spi2can.c - Core Driver Program Function: KV11Z SPI2CAN/ADC Linux kernel driver Implements CAN network device interface, supports standard Linux CAN Socket API Implements IIO ADC device interface, supports multi-channel ADC data acquisition Communicates with KV11Z microcontroller via SPI protocol Supports interrupt-driven high-performance data transfer Key Features: CAN Function: Supports standard and extended CAN frames, configurable baud rate and filters (under development) ADC Function: 8-channel ADC acquisition, supports triggered buffer mode and direct read mode High Performance: Multi-threaded architecture, supports concurrent CAN and ADC operations Configurable: Rich module parameters, supports runtime tuning Module Parameters: # CAN Configuration g_can_bitrate=1000000 # CAN baud rate (default 1Mbps) # ADC Configuration g_adc_mask=0xFF # ADC channel enable mask (default all channels) g_adc_sample_rate=1000 # ADC sampling rate (default 1kHz) # SPI Configuration spi_speed=7000000 # SPI bus speed (default 7MHz) transfer_time_us=30 # SPI transfer interval (default 30μs) # Debug Options debug=0 # Debug information switch (0=off, 1=on) 2. adctest.c - ADC Test Application Function: ADC data acquisition test tool Supports two ADC reading modes: direct mode and buffer mode Provides real-time data display and CSV file output Supports timestamps and performance statistics Hardware compatibility detection and channel validation Key Features: Dual Mode Support: Direct read mode (sysfs) and buffer mode (IIO buffer) Flexible Configuration: Configurable channel mask and sampling rate Data Export: Supports CSV format data export for subsequent analysis Real-time Display: Color terminal output and statistical information Usage Examples: # Compile gcc -O2 -o adctest adctest.c # Buffer mode, enable channels 0-3, with timestamps ./adctest -m 1 -c 0x0F -t # Direct mode, 500ms sampling interval ./adctest -m 0 -d 500000 # Save data to CSV file ./adctest -m 1 -f /tmp/adc_data # View help ./adctest -h 3. cantest.c - CAN Bus Test Tool Function: Comprehensive CAN bus testing and benchmarking tool Supports CAN frame generation, transmission and reception Provides MD5 verification to ensure data integrity Supports file transfer over CAN bus Real-time performance monitoring and statistical analysis Key Features: Performance Testing: Supports bulk transmission testing of large numbers of frames Data Integrity: MD5 verification ensures transmission data integrity File Transfer: Supports arbitrary file transfer over CAN bus Real-time Monitoring: Progress bar display, FPS statistics, error statistics, etc. Usage Examples: # Compile gcc -O2 -o cantest cantest.c # Transmitter: Send 1000 random CAN frames ./cantest -i can0 -t -n 1000 -d 1000 # Receiver: Receive CAN frames and verify ./cantest -i can0 -r # File transfer transmitter ./cantest -i can0 -t -f /path/to/file # File transfer receiver ./cantest -i can0 -r -f /path/to/output # View help ./cantest -h Quick Start 1. Environment Setup Ensure cross-compilation toolchain is installed: # Set cross-compilation environment source environment-setup-aarch64-toolchain 2. Build System # Complete build ./build.sh all # Or step-by-step build ./build.sh uboot ./build.sh kernel ./build.sh apps ./build.sh mkfs 3. Deploy Driver # Load driver module insmod kv11z_spi2can.ko # Configure CAN interface ip link set can0 type can bitrate 1000000 ip link set can0 up # Verify ADC device ls /sys/bus/iio/devices/ 4. Function Testing # Test ADC function ./adctest -m 1 -c 0xFF -t # Test CAN function ./cantest -i can0 -t -n 100 Technical Specifications Hardware Requirements Main Controller: OK-MX93 development board (IMX93 processor) Co-processor: KV11Z microcontroller Interface: SPI bus connection CAN: Supports CAN 2.0A/B protocol ADC: 8-channel 12-bit ADC Performance Metrics CAN Baud Rate: Up to 1Mbps ADC Sampling Rate: Up to 1kHz (per channel) SPI Speed: Up to 12.5MHz Latency: CAN frame transmission latency ≤1ms Throughput: Supports 7500 frames/second CAN transmission Software Compatibility Kernel Version: Linux 6.1.36 Architecture: ARM64 (aarch64) Compiler: GCC cross-compilation toolchain API: Standard Linux CAN Socket API, IIO subsystem API Troubleshooting Common Issues Compilation Failure Check if cross-compilation environment is correctly set Confirm all dependency packages are installed Driver Loading Failure Check if device tree configuration is correct Confirm SPI interface and GPIO configuration CAN Communication Abnormal Check CAN bus hardware connections Verify if baud rate configuration matches ADC Data Abnormal Check ADC channel mask configuration Verify if sampling rate setting is reasonable Debugging Methods # Enable driver debug information echo 1 > /sys/module/kv11z_spi2can/parameters/debug # View system logs dmesg | grep kv11z # Check device status cat /proc/interrupts | grep kv11z Technical Support For technical support, please contact the development team or refer to relevant technical documentation. Note: This software package is only applicable to OK-MX93 development board. Please ensure hardware configuration is correct before use.Other boards please porting by yourself. Disclaimer: "Any support, information, and technology ("Materials") provided by NXP are provided AS IS, without any warranty express or implied, and NXP disclaims all direct and indirect liability and damages in connection with the Material to the maximum extent permitted by the applicable law. NXP accepts no liability for any assistance with applications or product design. Materials may only be used in connection with NXP products. Any feedback provided to NXP regarding the Materials may be used by NXP without restriction."

This is a tool for screen capture under DRM (Direct Render Manager). This also a revised version for previous “drmfbcap” (DRM Framebuffer Capture). Unlike the FB based system under which we can capture the frame buffer easily through reading the device node, the DRM is much more complex and secure-protected. No direct way for reading framebuffer data from user space. Under DRM case, we need to open the DRM device, query the resource, get and map the FB object and then read the buffer eventually. With this tool, we can capture the buffer content from a DRM device and output as raw RGB/YUV data. Features: Capture all planes or specific plane, including hidden/covered planes or planes (overlays) managed by applications directly. Both RGB and YUV supported (auto detect). Tile format (VSI Super-Tile) is also supported. Repeat mode which can capture frames continuously. Tool was built as static linked, in this case, it should be working in both Linux and Android.   Important notes: Behavior of DRM subsystem is different between Linux 4.x and 5.x/6.x. For Linux 4.x, you can capture the RGB buffer without any problem. But, there’s no API for YUV (multi-plane) buffer. To capture YUV, please patch kernel with: “kernel_0001-drm-Add-getfb2-ioctl_L4.14.98.patch”. For Linux 5.x, mapping/capturing the internal buffer is not allowed by default due to security reason. To overcome this temporary (for debug only), patch the kernel with: “0001-drm-enable-mapping-of-internal-object-for-debugging_L5.x.patch”. It contains a minor change to remove this guard. Both patches are included in attachment. To get more details about how to use this tool, try “-h” option to print the usage message. Enjoy!

Hardware : i.MX8MNLPDDR4EVK Build Yocto Image [Linux 4.14.98_2.3.1] Yocto Project Setup          $: mkdir imx-yocto-bsp          $: cd imx-yocto-bsp                $: repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b imx-linux-sumo -m imx-4.14.98-2.3.1.xml          $: repo sync  copy marvell bb.file into yocto source         $: cp  0001-Porting-mrvl-8987-wifi.patch   imx-yocto-bsp/sources/meta-fsl-bsp-release/imx/meta-bsp         $: git apply 0001-Porting-mrvl-8987-wifi.patch Image Build         $: DISTRO=fsl-imx-xwayland MACHINE=imx8mnlpddr4evk source fsl-setup-release.sh -b build-xwayland         $:bitbake fsl-image-qt5-validation-imx Enable wifi and BT (These operations is on EVK) WiFi $:insmod /lib/modules/4.14.98-2.3.1+g860ec89/extra/sd8xxx.ko fw_name=/mrvl/sduart8987_combo.bin cal_data_cfg=none cfg80211_wext=0xf BT $:hciattach /dev/ttymxc0 any -s 115200 115200 flow dtron $:hciconfig hci0 reset $:hcitool -ihci0 cmd 0x3f 0x0009 0xc0 0xc6 0x2d 0x00 & $:killall hcitool $:killall hciattach $:hciattach /dev/ttymxc0 any -s 3000000 3000000 flow dtron Build  Android Image[Android P9_2.3.4] These patches in  Android-2.3.4-patch. Getting i.MX Android release source code        $: cd ~ (or any other directory you like)        $: tar xzvf imx-p9.0.0_2.3.4.tar.gz        $: mkdir ~/bin        $: curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo        $: chmod a+x ~/bin/repo        $: export PATH=${PATH}:~/bin        $: source ~/imx-p9.0.0_2.3.0/imx_android_setup.sh        # By default, the imx_android_setup.sh script will create the source code build environemnt        in the folder ~/android_build        # ${MY_ANDROID} will be refered as the i.MX Android source code root directory in all i.MX        Andorid release documentation.        $ : export MY_ANDROID=~/android_build Copy 88W8987 firmware and driver into  Android release code        $:copy -r Android-2.3.4-patch/mrvl    android_build/vendor/nxp/fsl-proprietary  Apply these patches.The name of these patches is the patche installation path.            example:  0001-android_build-hardware-marvell-wlan.patch         $: cp 0001-android_build-hardware-marvell-wlan.patch   android_build/hardware/marvell/wlan            (if not exist android_build/hardware/marvell/wlan, mkdir -p android_build/hardware/marvell/wlan)         $: git apply 0001-android_build-hardware-marvell-wlan.patch  Building Android images          $: cd  android_build          $: source build/envsetup.sh          $: lunch evk_8mn-userdebug          $: make 

In the old Android release R10.3.x for i.MX5x, I had followed the user guide instructions to install the USB driver and am able to setup the ADB connection successfully. Unfortunately, for the same PC, the ADB fails to detect my i.MX6SL EVK which is using R13.5. Updating the Android SDK tools cannot help. The reason is the new Android device is using a different USB VID from the old release. So, to solve this problem, we need to update the ADB configuration to scan for the new vendor ID. Below are the steps to update the ADB configuration for Windows PC. These steps (and the steps for Linux PC as well) can also be found in the R10,3.x user guide. 1. Run the SDK's tools to generate an ADB configure file: C:\Program Files\Android\android-sdk\tools> android.bat update adb 2. Modify the adb usb configure file to add the new vendor id 0x18d1. File: X:\Profile\<your account>\.android\adb_usb.ini # ANDROID 3RD PARTY USB VENDOR ID LIST -- DO NOT EDIT. # USE 'android update adb' TO GENERATE. # 1 USB VENDOR ID PER LINE. 0x15a2 0x18d1 3. Unpack the Freescale Android USB win driver "android_usb_fsl.zip" in your Android BSP release package. If you can't find this file in your current package, please get the R10.3.x release for i.MX5x and unpack it. 4. File "tetherxp.inf" in the unpacked "android_usb_fsl" may not be the updated one if the "android_usb_fsl.zip" is extracted from an old release. So, please overwrite the file "tetherxp.inf" in unpacked "android_usb_fsl.zip" by the new "tetherxp.inf" in your current Android BSP release. 5. Enable the "USB debugging" option on the i.MX6 device System settings -> Developer options -> USB debugging 6. Connect the Android Device into PC, uninstall your old driver named "Android Phone" in the device manager, then re-install driver by scanning and locating .inf file under the directory you unpack the android_usb_fsl.zip manually. 7. Restart the ADB server C:\Program Files\Android\android-sdk\platform-tools> adb kill-server C:\Program Files\Android\android-sdk\platform-tools> adb start-server 8. Finally, test your ADB connection C:\Program Files\Android\android-sdk\platform-tools> adb devices List of devices attached 0123456789ABCDEF     device Congratulations! Your ADB is now working. If you have additional information about this topic, please feel free to comment. This document was generated from the following discussion: i.MX6: Android connect to ADB

i.MX93 DDR stress test tool is different with previous i.MX tool. This Chinese article describe how to debug i.MX93 DDR and introduce DDR config tool usage.

What is Automotive Grade Linux? Automotive Grade Linux is a collaborative, open source project that brings together automakers, suppliers, and technology companies for the purpose of building Linux-based, open source software platforms for automotive applications that can serve as de facto industry standards. AGL address all software in the vehicle: infotainment, instrument cluster, heads-up-display (HUD), telematics, connected car, advanced driver assistance systems (ADAS), functional safety, and autonomous driving. Architecture The Automotive Grade Linux Software Architecture diagram is below. The architecture consists of five layers. The App/HMI layer contains applications with their associated business logic and HMI. The Application Framework layer provides the APIs for creating both managing and running applications on an AGL system. The Services layer contains user space services that all applications can access. The Operating System (OS) layer provides the Linux kernel and device drivers along with standard OS utilities. For IVI (In Vehicle Infotainment) system a full fledged demo is available. Supported Boards The following table briefs about the various hardware platforms, supported by AGL : BOARD $MACHINE ARCHITECHTURE BeagleBone bbe arm32   beaglebone arm32       i.MX 6 cubox-i arm32   imx6qdlsabreauto arm32   nitrogen6x arm32       i.MX 8 imx8mqevk arm64   imx8mqevk-viv arm64       Snapdragon dragonboard-410c arm64   dragonboard-820c arm64       ARC HS hsdk ARC       virtio virtio-aarch64 arm64   AGL Components AGL includes some major components showing as follow: agl-compositor waltham-receiver_waltham-transmitter rba drm-leasemanager appfw cynagora. pyagl pipewire_wireplumber agl-compositor When the AGL project was started, weston was chosen as the compositor, which is the reference implementation of a Wayland compositor, while for window management functionality it relied on ivi-shell (In-Vehicle Infotainment) together with an extension, called wayland-ivi-exension.   Waltham protocol is a IPC library similar to Wayland, developed with networking in mind. It operates over TCP sockets, while the wayland protocol only works locally over a UNIX socket. It retains wayland-esque paradigm, making use of XMLs to describe the protocol, and it follows an object-oriented design with an asynchronous architecture. DRM Lease Manager The DRM Lease Manager is used in AGL to allocate display controller outputs to different processes. Each process has direct access to its allocated output via the kernel DRM interface, and is prevented from accessing any other outputs managed by the display controller. PyAGL  PyAGL was written to be used as a testing framework replacing the Lua afb-test one, however the modules are written in a way that could be used as standalone utilities to query and evaluate apis and verbs from the App Framework Binder services in AGL. PipeWire / WirePlumber AGL uses the PipeWire daemon service to provide audio playback and capture capabilities. PipeWire is accompanied by a secondary service, WirePlumber (also referred to as the session manager), which provides policy management, device discovery, configuration and more. Applications can connect to the PipeWire service through its UNIX socket, by using either the libpipewire or libwireplumber libraries as a front-end to that socket. How to port AGL in i.MX8qm get agl source as follow: repo init -b koi -uhttps://git.automotivelinux.org/AGL/AGL-repo repo sync apply patches in attachment add file agl_imx8qmmek.inc to path 'meta-agl\meta-agl-bsp\conf\include'. add files 40_bblayers.conf.inc, 50_local.conf.inc and 50_setup.sh to path 'meta-agl\templates\machine\imx8qmmek'. build as follow: source meta-agl/scripts/aglsetup.sh -f -m imx8qmmek agl-demo bitbake agl-demo-platform Then the wic image can be flashed into i.mx8qm showing as below:

1.- Set SW602 Boot mode pin settings to Serial Downloader mode 2.-Connect JTAG debug probe and turn on the board 3.-Run script to bring-up DRAM In Lauterbach this script is called 'mcimx6ul_sieve_dram.cmm' under the mcimx6ul folder, the scripts can be found here and are also attached (download the imx6ultralite package). If you are not using Lauterbach please ask your probe vendor for a similar script. NOTE: this u-boot image has been built to run off DRAM if your bootloader runs from OCRAM you might not need a script. While running the script you might be prompted with and error telling you there is a syntax error in the script system.cpu IMX6ULL simply edit the script and change the CPU name to IMX6ULTRALITE 4.- Load u-boot.srec to DRAM and start executing it The srec is being used in this case because it contains the addresses where the binary needs to be loaded and the entry point for the application is automatically recognised and set by Lauterbach. To load it simply issue 'data.load.S3record u-boot.srec' and then click on go to let it run. You should now be able to see the output from u-boot on the console hit any key on the console to stop the boot process. 5.- Load QuadSPI configuration to DRAM and flash it to the memory The Boot ROM on the i.MX6UL requires the configuration data for the QuadSPI memory to be stored at address 0x400 of the QuadSPI memory, the length of this configuration data is 512 bytes. Attached is a configuration binary that can be used for the NOR flash memory used in the i.MX6UL EVK. For more details on the configuration parameters please refer to chapter '8.6.3 QuadSPI Configuration Parameters' of the i.MX6UL Reference Manual. Stop the execution on T32 (Lauterbach's environment) and load the configuration to DRAM by issuing 'data.load.binary QSPI_cfg2.bin 0x90000000' and resume execution. On u-boot execute the 'sf probe' command (sf stands for Serial Flash) to detect the memory. You should see an output like the following: => sf probe SF: Detected N25Q256 with page size 256 Bytes, erase size 4 KiB, total 32 MiB Now issue the sf erase command to erase the first sector (remember our erase size is of 4KiB): => sf erase 0x0 0x1000 SF: 4096 bytes @ 0x0 Erased: OK Now we are ready to write our configuration to address 0x400 => sf write 0x90000000 0x400 0x200 SF: 512 bytes @ 0x400 Written: OK 6.- Load u-boot.imx to DRAM and download it to memory. We will follow the same procedure to download the u-boot image to the memory. Stop execution on Lauterbach and load u-boot.imx to DRAM using 'data.load.binary u-boot_SPI.imx 0x90000000' and resume execution (u-boot.imx contains the IVT header which basically stores all the information the device needs to boot u-boot.bin and u-boot.imx). The boot ROM expects to find the IVT header at address 0x1000 of the SPI NOR Flash memory. We will load u-boot.imx to this address by issuing 'sf update 0x90000000 0x1000 0x57830'(the size of u-boot.imx is 358448 bytes) this will erase and write the memory. => sf update 0x90000000 0x1000 0x57830 358448 bytes written, 0 bytes skipped in 23.741s, speed 15458 B/s If you want to verify that the image was flashed correctly you can read from QuadSPI to DRAM by issuing 'sf read 0x90000000 0x1000 0x57830 ' and verify the data. 7.- Now we can end our debug session and turn off our board Set SW602 to Internal boot mode (ON/OFF) and SW601 to select boot from QuadSPI (all OFF) Turn on the board again and you should be able to see u-boot's output on your terminal. This procedure can be used with other boards/i.MX6 derivatives, I am just posting the setup in which I tested it.

Overview This document explains how to use Pulse Width Modulation (PWM) on the iMX93 EVK Board. Attached to this post is a patch to enable this functionality, which can be integrated into either Yocto or a standalone kernel compilation.   This procedure was tested on iMX93 EVK A0 silicon version with BSP 6.1.22 version, this feature should work on A1 silicon version too but is not tested yet.   Kernel Configuration: To enable PWM support, modify the imx_v8_defconfig  file by adding the following line: CONFIG_PWM=y CONFIG_PWM_ADP5585=y CONFIG_PWM_CROS_EC=m CONFIG_PWM_FSL_FTM=m CONFIG_PWM_IMX27=y CONFIG_PWM_RPCHIP=y CONFIG_PWM_SL28CPLD=m + CONFIG_PWM_IMX_TPM=y​ # Add this line   Device Tree Modifications: You will need to add the following nodes to the device tree to configure the TPM (Timer/Pulse Width Modulation) controller:   + &tpm4 { + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_tpm4>; + status = "okay"; + }; ... + pinctrl_tpm4: tpm4grp { + fsl,pins = < + MX93_PAD_GPIO_IO05__TPM4_CH0 0x19e //EXP_GPIO_IO05 J1001 29 + >; + };​   Compiling and Flashing: After making the above changes, compile the kernel and device tree. Once the compilation is complete, flash the new image and device tree to the iMX93 EVK Board.  PWM Configuration on the Board After flashing, you can configure the PWM settings on the board. Open a terminal and execute the following commands: $ cd /sys/class/pwm/pwmchip1/ $ echo 0 >> export $ echo echo 2000000 >> pwm0/period # Set period to 2,000,000 ns (2 ms) $ echo echo 1000000 >> pwm0/duty_cycle # Set duty cycle to 1,000,000 ns (1 ms) $ echo 1 >> pwm0/enable   Validation To validate the PWM output signal, check pin 29 of connector J1001 on the iMX93 EVK Board.   Conclusion Following these steps should enable PWM functionality on your iMX93 EVK Board. If you encounter any issues, please refer to the documentation or reach out for assistance. Best Regards! Chavira

  For some applications, we need to reduce the CPU Frequency, but if you are not familiar with our BSP or our devices probably you need some help to do some configurations.   In this post, I will share the configuration to set up lower frequencies (100MHz, 200MHz, 400Mhz, 600MHz, 800MHz, and 1000MHz) on iMX8MP, iMX8MN, and iMX8MM.   Note: Works on Kernel 6.1.xx (not tested on oldest BSP)   1- We have to modify the PLL driver to set the proper parameters to lower frequencies. The file to modify is "clk-pll14xx.c" adding the following lines:   https://github.com/nxp-imx/linux-imx/blob/770c5fe2c1d1529fae21b7043911cd50c6cf087e/drivers/clk/imx/clk-pll14xx.c#L57   static const struct imx_pll14xx_rate_table imx_pll1416x_tbl[] = { PLL_1416X_RATE(1800000000U, 225, 3, 0), PLL_1416X_RATE(1600000000U, 200, 3, 0), PLL_1416X_RATE(1500000000U, 375, 3, 1), PLL_1416X_RATE(1400000000U, 350, 3, 1), PLL_1416X_RATE(1200000000U, 300, 3, 1), PLL_1416X_RATE(1000000000U, 250, 3, 1), PLL_1416X_RATE(800000000U, 200, 3, 1), PLL_1416X_RATE(750000000U, 250, 2, 2), PLL_1416X_RATE(700000000U, 350, 3, 2), PLL_1416X_RATE(600000000U, 300, 3, 2), + PLL_1416X_RATE(400000000U, 200, 3, 2), + PLL_1416X_RATE(200000000U, 200, 3, 3), + PLL_1416X_RATE(100000000U, 200, 3, 4), };   2- Once the pll driver has been modified, only we have to add the values on the opp-table according to the device that you will use.   2.1- For iMX 8MP:   https://github.com/nxp-imx/linux-imx/blob/lf-6.1.y/arch/arm64/boot/dts/freescale/imx8mp.dtsi         a53_opp_table: opp-table { compatible = "operating-points-v2"; opp-shared; + opp-100000000 { + opp-hz = /bits/ 64 <100000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0x8a0>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-200000000 { + opp-hz = /bits/ 64 <200000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0x8a0>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-400000000 { + opp-hz = /bits/ 64 <400000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0x8a0>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-600000000 { + opp-hz = /bits/ 64 <600000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0x8a0>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-800000000 { + opp-hz = /bits/ 64 <800000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0x8a0>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-1000000000 { + opp-hz = /bits/ 64 <1000000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0x8a0>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; opp-1200000000 { opp-hz = /bits/ 64 <1200000000>;   2.2 For iMX8MM:   https://github.com/nxp-imx/linux-imx/blob/lf-6.1.y/arch/arm64/boot/dts/freescale/imx8mm.dtsi     a53_opp_table: opp-table { compatible = "operating-points-v2"; opp-shared; + opp-100000000 { + opp-hz = /bits/ 64 <100000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xe>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-200000000 { + opp-hz = /bits/ 64 <200000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xe>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-400000000 { + opp-hz = /bits/ 64 <400000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xe>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-600000000 { + opp-hz = /bits/ 64 <600000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xe>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-800000000 { + opp-hz = /bits/ 64 <800000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xe>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-1000000000 { + opp-hz = /bits/ 64 <1000000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xe>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; opp-1200000000 { opp-hz = /bits/ 64 <1200000000>;   2.3- For iMX8MN:   https://github.com/nxp-imx/linux-imx/blob/lf-6.1.y/arch/arm64/boot/dts/freescale/imx8mn.dtsi   compatible = "operating-points-v2"; opp-shared; + opp-100000000 { + opp-hz = /bits/ 64 <100000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xb00>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + + opp-200000000 { + opp-hz = /bits/ 64 <200000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xb00>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + + opp-400000000 { + opp-hz = /bits/ 64 <400000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xb00>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + + opp-600000000 { + opp-hz = /bits/ 64 <600000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xb00>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + + opp-800000000 { + opp-hz = /bits/ 64 <800000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xb00>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + + opp-1000000000 { + opp-hz = /bits/ 64 <1000000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xb00>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-1200000000 { opp-hz = /bits/ 64 <1200000000>; opp-microvolt = <850000>;   After that, you should note the changes under Linux.   These commands return information about the system and the current settings.   • The kernel is pre-configured to support only certain frequencies. The list of frequencies currently supported can be obtained from: cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies   • To get the available scaling governors: cat /sys/devices/system/cpu/*/cpufreq/scaling_available_governors   • To check the current CPU frequency: cat /sys/devices/system/cpu/*/cpufreq/cpuinfo_cur_freq   The frequency is displayed depending on the governor set.   • To check the maximum frequency: cat /sys/devices/system/cpu/*/cpufreq/cpuinfo_max_freq   • To check the minimum frequency: cat /sys/devices/system/cpu/*/cpufreq/cpuinfo_min_freq   These commands set a constant CPU frequency:   • Use the maximum frequency: echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor   • Use the current frequency to be the constant frequency: echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor   • The following two commands set the scaling governor to a specified frequency, if that frequency is supported.   If the frequency is not supported, the closest supported frequency is used:   echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo <frequency> > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed    

1 - Introduction: The Ultra Secured Digital Host Controller (uSDHC) provides the interface between the host processor and the SD/SDIO/MMC cards. Most recent versions provides the ability to automatically select a quantized delay (in fractions of the clock period) regardless of on-chip variations such as process, voltage, and temperature (PVT). The auto tuning is performed during runtime at hardware level, no software enablement is needed to drive this feature. 2 - Failure description: SDIO cards can implement an optional feature that uses DATA[1] to signal the card's interrupt to the i.MX device, this feature can be enabled by the SDIO card device and does not depends on i.MX uSDHC driver configuration. NXP Linux BSP is enabling the auto tuning for high SDIO frequencies (SDR104 and SDR50). Out of reset uSDHC_VEND_SPEC2 register is configured to use DATA[3:0] for calibration, this setup can conflict with the SDIO interrupt as DATA[1] signal can be asserted asynchronously. SDIO failures can be observed when running SDIO applications that requires high usage of the SDIO interface (e.g Download of large files), SDIO controller cannot return an accurate DLL causing failures such as "CMD53 read error". Failure can be observed on i.MX8MM EVK and i.MX8MN EVK boards, both devices are running 88w8987 Wi-Fi chipset at 208Mhz (SDR104). Users can observe an SDIO crash followed by error message below at Linux Kernel level. [ 401.945627] cmd53 read error=-84 [ 401.974677] moal_read_data_sync: read registers failed 3 - Impacted devices: The following devices are impacted by this limitation. - i.MX6 Family:   i.MX6SL, i.MX6SLL, i.MX6SX, i.MX6UL, i.MX6ULZ and i.MX6ULL. - All i.MX7 and i.MX7ULP family:   i.MX7D, i.MX7S and i.MX7ULP. - All i.MX8M Family:   i.MX8MQuad, i.MX8M Mini, i.MX8M Nano, i.MX8M Nano UL and i.MX8M Plus. - All i.MX8/8X Family:   i.MX8DQXP, i.MX8DX and i.MX8QM. NXP Linux BSP is enabling the auto tuning for SDR104 and SDR50 modes. Other operation modes are not impacted by this limitation. Users can poll uSDHCx_CLK_TUNE_CTRL_STATUS register when running SDIO applications to confirm. TAP_SEL_PRE field is updated automatically during run time and constant variations can point to an incorrect delay cell calculated by the uSDHC controller.   All NXP Wi-Fi chipsets are enabling SDIO interrupt during firmware load, failures can be observed with any Wi-Fi vendor enabling SDIO asynchronous interrupt. 4 - Software changes: Recommendation is to enable auto tuning for DATA[0] and CMD signals only, DATA[1] should not be used for auto calibration to avoid a possible conflict with SDIO interrupt. This setup can only be used if SDIO interface length are well matched. Software patches can be found at codeaurora.org. Fix is already included in L5.10.52-2.1.0 BSP, users can add fsl,sdio-interrupt-enabled property to uSDHC device tree node to enable SW workaround. https://github.com/nxp-imx/linux-imx/commit/3b3d6dec05277f7786d813592a31ea4a1ce60a74 https://github.com/nxp-imx/linux-imx/commit/b9b5a43df1d709809b2b654ad8f8181b00a4ee55 https://github.com/nxp-imx/linux-imx/commit/95a846af9f82dc6ea60064d9d12d5d2378e23941      

Attached is an application note for iMX6 TVIN use case, some internal review was done. 2016-10-08, change it to pdf file.

Getting Started for i.MX53 Quick Start Board Here is a quick overview you can follow to get your very first contact with i.MX53 QSB. Introduction Out of box i.MX53 QSB video booting up Ubuntu Original Video: Out of box i.MX53 QSB video booting up Ubuntu with some demo (GPU and VPU) Original Video: How to load a pre-built image Here, you should have loaded your board with the out-of-box SD card. Next step is create your own SD card with some pre-built image. You can find pre-built image packages from Freescale for Linux look for Linux Binary Demo file Please, go to Timesys wikipage[1] and see how to load a pre-built image. You can use some Freescale image or some Timesys image. Both will work! For loading linux OS you need at least 3 images: bootloader image kernel image root file system image or tarball Bootloader For iMX53QSB the default bootloader provided by Freescale is u-boot.You can build your own image using LTIB following the same procedure from here. Kernel You can build a new uImage (kernel binary image to be loaded by u-boot) using LTIB, and you can follow the instructions from here Root File System Root file system is a set of directories and files that become the system environment. How to Built Your Own Image Take BSP package on Freescale i.MX53 QSB web site. Prepare your computer to LTIB installation, see that you need All Boards LTIB. Transfer all images to the SD Card (it will be placed under <ltib_dir>/rootfs/boot). Configure your u-boot environment variable. Boot your board. In case you want to boot via NFS, please follow the next procedure instead. Take BSP package on Freescale i.MX 53 QSB web site. Prepare your computer to LTIB installation, see that you need @all_boards_ltib Configure your computer to be able to provide NFS service: Configure your TFTP server. Configure your NFS server. Configure your u-boot environment variable. Boot your board. Be aware the kernel command line you set on u-boot variable can configure the display.