$ ~/dylan/sources$ find -name *image*.bb ./meta-fsl-demos/recipes-fsl/images/fsl-image-gui-sdk.bb ./meta-fsl-demos/recipes-fsl/images/fsl-image-test.bb ./meta-fsl-demos/recipes-fsl/images/fsl-image-gui.bb ./meta-fsl-demos/recipes-qt/images/qt-in-use-image.bb ./meta-fsl-demos/recipes-qt/images/qte-in-use-image.bb ./meta-openembedded/meta-initramfs/recipes-bsp/images/initramfs-kexecboot-klibc-image.bb ./meta-openembedded/meta-initramfs/recipes-bsp/images/initramfs-kexecboot-image.bb ./meta-openembedded/meta-oe/recipes-support/imagemagick/imagemagick_6.7.5.bb ./meta-openembedded/meta-oe/recipes-multimedia/libsdl-image/libsdl-image_1.2.12.bb ./poky/meta-hob/recipes-core/images/hob-image.bb ./poky/meta-skeleton/recipes-multilib/images/core-image-multilib-example.bb ./poky/meta/recipes-devtools/mkelfimage/mkelfimage_svn.bb ./poky/meta/recipes-sato/images/core-image-sato-dev.bb ./poky/meta/recipes-sato/images/core-image-sato.bb ./poky/meta/recipes-sato/images/core-image-sato-sdk.bb ./poky/meta/recipes-qt/images/qt4e-demo-image.bb ./poky/meta/recipes-core/images/core-image-minimal.bb ./poky/meta/recipes-core/images/core-image-base.bb ./poky/meta/recipes-core/images/core-image-minimal-dev.bb ./poky/meta/recipes-core/images/core-image-minimal-initramfs.bb ./poky/meta/recipes-core/images/build-appliance-image.bb ./poky/meta/recipes-core/images/core-image-minimal-mtdutils.bb ./poky/meta/recipes-extended/images/core-image-lsb-sdk.bb ./poky/meta/recipes-extended/images/core-image-basic.bb ./poky/meta/recipes-extended/images/core-image-lsb-dev.bb ./poky/meta/recipes-extended/images/core-image-lsb.bb ./poky/meta/recipes-graphics/images/core-image-directfb.bb ./poky/meta/recipes-graphics/images/core-image-x11.bb ./poky/meta/recipes-graphics/images/core-image-clutter.bb ./poky/meta/recipes-graphics/xcb/xcb-util-image_0.3.9.bb ./poky/meta/recipes-bsp/u-boot/u-boot-mkimage_2013.01.01.bb ./poky/meta/recipes-bsp/u-boot/u-boot-mkimage_2011.06.bb ./poky/meta/recipes-bsp/u-boot/u-boot-mkimage_2011.03.bb ./poky/meta/recipes-rt/images/core-image-rt-sdk.bb ./poky/meta/recipes-rt/images/core-image-rt.bb Those are all available images. And note that, available images from poky and meta-fsl-arm only. As you may imagine, several other layers can be included, and any new layer can provide new images. If you look line by line, you can see that some of that files are not images, for example u-boot-mkimage_2011.06.bb but you got the message. Yocto Project (and meta-fsl-demos) provides some "pre baked" images. In my point of view, those images are not to be used on your product. They are examples and quick starting points. When you desire a pie, you can go to supermarket and buy a frozen chocolate pie. But when you´re developing a pie to be the Apple Salted Caramel with Dark Chocolate Cinnamon Topping you need to decide every piece of this pie. What is the base, which type of apple to use. How much salt on caramel. This is your product, your pie, not a frozen standard pie. I know the analogy is kind of dumb. But it´s important to understand that the "pre baked" images provided by Yocto Project, or meta-fsl-demos are not supposed to become a product image! You can (and maybe should) base your image on some of those images, but they are not good enough to your product. I highly recommend you to have your own image file. The pre-baked images I´m used with are core-image-minimal I use to image name I use it when/for Formal description core-image-minimal testing machine support; uboot support/upgrade; kernel support/upgrade A small image just capable of allowing a device to boot. core-image-base when I need to add something like ssh/dropbear or evtest or usb utils. I always configure this on local.conf to add the desired package. A console-only image that fully supports the target device hardware. core-image-x11 when I need to test X11 accelerated by GPU, or I need to have X11 for any test. A very basic X11 image with a terminal core-image-direcftb when I debug directfb GPU support An image that uses DirectFB instead of X11. core-image-weston when I debug Wayland GPU support A very basic Wayland image with a terminal fsl-image-test when I need to test VPU with and without gstreamer. - fsl-image-gui when I need to have QT, or I want to build everything altogether. Although I´ve been preferring the smaller images instead. - meta-toolchain To have the crosscompiler installed on my machine to manually build u-boot and kernel, when I´m changing it Meta package for building a installable toolchain All those images DO NOT include -dev packages or native build. If you want it you MUST configure your local.conf. Although, you can find special images that provides the header files or the native compiler. The images with -dev sufix include the header files (and development files) from all packages. For example: core-image-minimal-dev ( A small image just capable of allowing a device to boot and is suitable for development work. ) The images with -sdk sufix include the native build tools. For example core-image-sato-sdk ( Image with Sato support that includes everything within core-image-sato plus meta-toolchain, development headers and libraries to form a standalone SDK. ) *all formal description was copied from poky source code (poky - Poky Build Tool and Metadata) Please, go back to Yocto Training - HOME

Current the SSI is set to I2S slave mode in FSL default release BSP. attached the code for how to set it to master mode.

The NXP i.MX 8M provides industry leading audio, voice and video processing for applications that scale from consumer home audio to industrial building automation and mobile computers. The i.MX 8M Quad supports multiple audio interfaces as listed below: Besides the general audio input/output function, the audio interfaces will supports following features: - SAI-1 supports up to 16-channels TX (8 lanes) and 16-channels RX (8 lanes) at 384KHz/32-bit. - SAI-5 supports up to 8-channels TX (4 lanes) and 8-channels RX (4 lanes) at 384KHz/32-bit. - SAI-2/3/6 supports up to 2-channels TX (1 lanes) and 2-channels RX (1 lanes) at 384KHz/32-bit. - SAI-2/3/6 support up to 2-channels TX (1 lane) and 2-channels RX (1 lane) at 384KHz/32-bit. - SAI-1 supports glue-less switching between PCM & DSD operation for popular audio DACs - SPDIF-1/2 supports raw capture mode that can save all the incoming bits into audio buffer The SAI-1/2/3/5/6 and SPDIF-1 share GPIO pads on the chip through IOMUX. Common use cases supported by the audio interfaces are listed in the table below (many other configurations are possible). The number is the data lanes supported. For the MCLK pin on each SAI module, it can be configured as either input or output. When configured as output, the SAI_CLK_ROOT from CCM will be routed to the pad output. When configured as input, the external input to the pad will be routed to SAI.MCLK, which can be used as master clock for SAI. Below is the diagram showing the both input/output options, by using SAI1 as the example. Each SAI module supports up to 3 master clock inputs. The TX and RX sub-module inside each SAI can independently select one of the clock inputs as its master clock. This allows TX and RX of one SAI to run from different clock source. The master clock inputs have following options: - SAI.MCLK[1] can be selected from SAI_CLK_ROOT from CCM or SAI.MCLK from IOMUX. This is the most straight-forward clock routing in which SAI only use its own clock source from CCM or IO pad. - SAI.MCLK[2] can be selected from following clock sources:       Any of the SAI_CLK_ROOT from CCM;       Any of the SAI.MCLK from IOMUX;       Other clock sources from SPIDF; - SAI.MCLK[3] has exact same clock source options as SAI.MCLK[2]. This allows both TX and RX can have access to all the options without any dependency between each other. The clock options for master clock on SAI are shown in the diagram blow, by using SAI-1 as an example. The options on MCLK[1] is also available on MCLK[2] and MCLK[3]. The reason to keep this options is to provide the similar SAI clock structure as i.MX6/i.MX7 processors. The configuration of the MUX for master clock are controlled by IOMUXC_GPR registers. They should be configured before SAI clock is enabled to avoid glitches on the clock. Note: Because those MUX on clocks are missed during the design, the actual implementation in the silicon is simplified as shown in the following diagram. All the SAI and SPDIF instances have SDMA support. In order to meet the audio data rate, two SDMA modules are used. Because the SAI-2/3 and SPDIF-1/2 do not require high data throughput, they are assigned to SDMA-1, shared with other peripherals such as UART/SPI. SAI-1/4/5/6 need to support high sample rate & multichannel audio, they are assigned to SDMA-2, which is a dedicated SDMA engine for audio. The SDMA-2 frequency is increased to 500/250 instead of 133/66 to make sure it has enough throughput. In order to allow SW tracking the progress of audio DMA, the TX_SYNC and RX_SYNC of SAI modules are routed to GPT as the external clock input. Since there are totally 6 SAI modules, these signals will be MUXed when connection to GPT. - GPT-4/5/6 external clock input can be selected from the TX_SYNC or RX_SYNC of any 6 SAI modules; - The MUX select is controlled by IOMUXC_GPR register; - The MUX select register for GPT-4/5/6 are fully independent of each other.

Computer On Module • Processor Freescale i.MX287, 454 MHz • RAM 128MB DDR2-400 SDRAM • ROM 128MB NAND Flash • Power supply Single 3.1V to 5.5V • Size 40mmX35mm • Temp.-Range -40°C..85°C Key Features • Two 10/100Mbps Ethernet ports with IEEE1588 support • Two High-Speed USB 2.0 ports • One colour LCD controller • Two CAN interfaces • 4 wire Touchscreen interface • Several peripheral interfaces: UART, SD-CARD, I2C, PWM, Serial Audio, SPI • Power management optimized for long battery life • 3.3V I/O OS Support • Windows Embedded CE 6.0 • Linux 2.6.35 Application：Building control, factory automation, printers and security panels, HMI, industrial control media gateways / accessories, portable medical devices, energy-saving Energy Gateway / Meter For more information, please see Attachment We can provide a complete solution

ADB ADB is a tool for Android debugging. With ADB, you can install applications from you PC, copy files to/from your device, access console. You can access your device using an USB Cable, or through network (using an IP address). You can take ADB from SDK [1] or inside <my_android>/out/host/linux-x86/bin/adb I cannot see my device First checkpoint must be for ADBD. It´s the ADB daemon, and if it´s not running on your device, you will not be able to access it. Install and configure any USB driver [2] [3] Double check connection (USB cable, ethernet) Double check if debugging is on Double check if USB config is right (see how on User Guide) Tips and Tricks Turning on Remember to turn debugging mode on: Settings->Applications->Development->USB debugging No Permission When you get "no permissions" from ADB, you need to start server with your root user: $ sudo /usr/share/android-sdk-linux_86/tools/adb devices List of devices attached ????????????    no permissions $ sudo /usr/share/android-sdk-linux_86/tools/adb shell error: insufficient permissions for device $ sudo /usr/share/android-sdk-linux_86/tools/adb kill-server $ sudo /usr/share/android-sdk-linux_86/tools/adb start-server * daemon not running. starting it now * * daemon started successfully * $ sudo /usr/share/android-sdk-linux_86/tools/adb devices List of devices attached 0123456789ABCDEF    device $ sudo /usr/share/android-sdk-linux_86/tools/adb shell # ls dev etc

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

The ARD has 2 LVDS connectors, one on the CPU board and a second one on the main board, the LVDS panel (MCIMX-LVDS1) can be connected to these. To enable two independent displays on the Linux BSP 11.05: 1. On u-boot, use the following on the kernel command line for video: video=mxcdi0fb:RGB666,XGA di0_primary ldb=di0 video=mxcdi1fb:RGB666,XGA ldb=di1 2. After boot use  memtool to write to the LDB registers to map each LVDS to a display interface: root@freescale ~$ /unit_tests/memtool -32 0x53fa8008=0x0000020d Writing 32-bit value 0x20D to address 0x53FA8008 3. Unblank framebuffer 1: echo 0 > /sys/class/graphics/fb1/blank On the Freescale Linux BSP 11.09 the LDB register write is not needed: 1. On U-boot, use the following on the kernel command line for video: 'video=mxcdi0fb:RGB666,XGA di0_primary ldb=separate,di=0,di=1,ch0_map=SPWG,ch1_map=SPWG video=mxcdi1fb:RGB666,XGA' 2. Unblank framebuffer 1: echo 0 > /sys/class/graphics/fb1/blank

Related links: i.MX Power Profiling System: Smart Current Sensor and Aggregator Shield  i.MX Power Profiling System: Aggregator Shield Details   i.MX Power Profiling: Triple-range Smart Current Sensor   Examples of boards instrumented with Smart Sensors. (Some close-ups will be added later.) One rail of the i.MX7ULP SOM is instrumented here. The sensor is immobilized with foam double sticky tape on top of the i.MX7ULP (trying to minimize contact to just that so the tape is more easily removed later). Immobilization is necessary in order to prevent ripping the resistor pads off the target board. The series resistor on the board is removed and the smart sensor is wired into place. Note here that the sensor is shorted so that the SOM will operate while the Smart Sensor being unpowered. The Smart Sensors MUST be powered via the Aggregator in order for the target board to operate. Otherwise, the target board will be starved of power and it will not operate unless all of the Smart Sensors connected to it are powered. An unpowered Smart Sensor presents an open circuit between the input and output terminals. Here are nine rails instrumented on the i.MX8QM CQC board. One rail Smart Sensor is in the bottom side, the rest are all on top. There is one double sticky taped to the back of the connectors at the back of the photo (the SCU supply, relatively low current, which can tolerate longer wires/series resistance). The rest are connected with 24 gauge wire, no longer than about half an inch long, to keep the series resistance low. The ground wire (center contact) can be a 30 gauge wire-wrap wire, which was used for all the grounds here. Note that the stiff connection wires allow the sensors to stand up in place, which is very helpful since there is no room to double sticky tape the sensors down. This board was not laid out with instrumentation in mind. Here is an i.MX8QXP CQC board with four rails instrumented. Two of the sensors are on top and two on the the bottom. They are not double sticky taped into place, but they are shielded with heat shrink tubing to prevent any contact with the target board. As above, 24 gauge wires are used for the current in/out lines, 30 gauge wire is used for all the ground contacts. Out of the frame, the four ribbon cables are bundled together to prevent the wires and sensors from moving too much. As above, the heavy wires have been kept as short as possible.

First execute LTIB (./ltib -c) and select these packages: all gstreamer plugin, alsa-utils and libmad. Create your file code (i.e.: playmp3.c): #include <gst/gst.h> #include <glib.h> static gboolean   bus_call (GstBus    *bus,             GstMessage *msg,             gpointer    data) {   GMainLoop *loop = (GMainLoop *) data;   switch (GST_MESSAGE_TYPE (msg)) {           case GST_MESSAGE_EOS:               g_print ("End of stream\n");               g_main_loop_quit (loop);               break;           case GST_MESSAGE_ERROR: {               gchar  *debug;               GError *error;               gst_message_parse_error (msg, &error, &debug);               g_free (debug);               g_printerr ("Error: %s\n", error->message);               g_error_free (error);               g_main_loop_quit (loop);               break;         }         default:           break;     }     return TRUE; } int main (int  argc,               char *argv[]) {       GMainLoop *loop;       GstElement *pipeline, *source, *decoder, *conv, *resample, *sink;       GstBus *bus;       /* Initialisation */       gst_init (&argc, &argv);       loop = g_main_loop_new (NULL, FALSE);       /* Check input arguments */       if (argc != 2) {           g_printerr ("Usage: %s <MP3 filename>\n", argv[0]);           return -1;       }         /* Create gstreamer elements */       pipeline = gst_pipeline_new ("audio-player");       source  = gst_element_factory_make ("filesrc",      "file-source");       decoder  = gst_element_factory_make ("mad",      "mp3-decoder");       conv    = gst_element_factory_make ("audioconvert",  "converter");       resample = gst_element_factory_make ("audioresample", "audio-resample");       sink    = gst_element_factory_make ("autoaudiosink", "audio-output");       if (!pipeline || !source || !decoder || !conv || !resample || !sink) {           g_printerr ("One element could not be created. Exiting.\n");           return -1;       }       /* Set up the pipeline */       /* we set the input filename to the source element */       g_object_set (G_OBJECT (source), "location", argv[1], NULL);         /* we add a message handler */         bus = gst_pipeline_get_bus (GST_PIPELINE (pipeline));         gst_bus_add_watch (bus, bus_call, loop);         gst_object_unref (bus);         /* we add all elements into the pipeline */         /* file-source | mp3-decoder | converter | resample | alsa-output */         gst_bin_add_many (GST_BIN (pipeline),                                                       source, decoder, conv, resample, sink, NULL);           /* we link the elements together */           /* file-source -> mp3-decoder -> converter -> resample -> alsa-output */           gst_element_link_many (source, decoder, conv, sink, NULL);         /* Set the pipeline to "playing" state*/         g_print ("Now playing: %s\n", argv[1]);         gst_element_set_state (pipeline, GST_STATE_PLAYING);         /* Iterate */       g_print ("Running...\n");       g_main_loop_run (loop);         /* Out of the main loop, clean up nicely */         g_print ("Returned, stopping playback\n");       gst_element_set_state (pipeline, GST_STATE_NULL);       g_print ("Deleting pipeline\n");       gst_object_unref (GST_OBJECT (pipeline));           return 0; } Create a directory inside your ltib directory to compile your source code: $ mkdir ~/your-ltib-dir/rpm/BUILD/gst Enter on LTIB shell mode: $ ./ltib -m shell Entering ltib shell mode, type 'exit' to quit LTIB> Enter in your application dir: LTIB> cd rpm/BUILD/gst/ Compile your application: LTIB> gcc -Wall $(pkg-config --cflags --libs gstreamer-0.10) playmp3.c -o playmp3 If everything worked file you will get a "playmp3" arm binary: LTIB> file playmp3 playmp3: ELF 32-bit LSB executable, ARM, version 1 (SYSV), for GNU/Linux 2.6.14, dynamically linked (uses shared libs), not stripped Now just copy it to ~/your-ltib-dir/rootfs/home. Start your board using this rootfs and execute: root@freescale ~$ cd /home/ root@freescale /home$ ./playmp3 your-file.mp3 Now playing: your-file.mp3 Running...

Some of Chinese customer couldn’t normally download android source code from google site, here give a way to download android source from Mirror site of Tsinghua University. Preparations 1. Installing Ubuntu16.04.2 LTS Customer can download ubuntu-16.04.2-desktop-amd64.iso from https://www.ubuntu.com/download/desktop Then install it to VMware workstation player v12 or PC, after finishing installation, use “Software Update” to update system. In order to compile android9.0.0-2.0.0 BSP, necessary packages should also be installed on Ubuntu 16.04. $ sudo apt-get install gnupg $ sudo apt-get install flex $ sudo apt-get install bison $ sudo apt-get install gperf $ sudo apt-get install build-essential $ sudo apt-get install zip $ sudo apt-get install zlib1g-dev $ sudo apt-get install libc6-dev $ sudo apt-get install lib32ncurses5-dev $ sudo apt-get install x11proto-core-dev $ sudo apt-get install libx11-dev $ sudo apt-get install lib32z1-dev $ sudo apt-get install libgl1-mesa-dev $ sudo apt-get install tofrodos $ sudo apt-get install python-markdown $ sudo apt-get install libxml2-utils $ sudo apt-get install xsltproc $ sudo apt-get install uuid-dev:i386 liblzo2-dev:i386 $ sudo apt-get install gcc-multilib g++-multilib $ sudo apt-get install subversion $ sudo apt-get install openssh-server openssh-client $ sudo apt-get install uuid uuid-dev $ sudo apt-get install zlib1g-dev liblz-dev $ sudo apt-get install liblzo2-2 liblzo2-dev $ sudo apt-get install lzop $ sudo apt-get install git-core curl $ sudo apt-get install u-boot-tools $ sudo apt-get install mtd-utils $ sudo apt-get install android-tools-fsutils $ sudo apt-get install openjdk-8-jdk $ sudo apt-get install device-tree-compiler $ sudo apt-get install gdisk $ sudo apt-get install liblz4-tool $ sudo apt-get install m4 $ sudo apt-get install libz-dev More detail, see Android_User’s_Guide.pdf ( android 9.0.0-2.0.0 BSP documents) 2. Downloading and unpacking Android release package [ For android 9.0.0_2.2.0, see commemts, please!] https://www.nxp.com/support/developer-resources/evaluation-and-developmentboards/ sabre-development-system/android-os-for-i.mx-applicationsprocessors: IMXANDROID?tab=Design_Tools_Tab -- P9.0.0_2.0.0_GA_ANDROID_SOURCE File name is imx-p9.0.0_2.0.0-ga.tar.gz # cd ~ # tar xzvf imx-p9.0.0_2.0.0-ga.tar.gz Downloading Android 9.0.0-2.0.0 source code 1. Getting repo # cd ~ # mkdir bin # cd bin # curl https://mirrors.tuna.tsinghua.edu.cn/git/git-repo > ~/bin/repo # chmod a+x ~/bin/repo # export PATH=${PATH}:~/bin 2. Modifying repo File Open ~/bin/repo file with 'gedit' and Change google address From REPO_URL = 'https://gerrit.googlesource.com/git-repo' To REPO_URL = ' https://mirrors.tuna.tsinghua.edu.cn/git/git-repo/ ' 3、Setting email address # git config --global user.email "[email protected]" # git config --global user.name "xxxx" [ Email & Name should be yours] 4、Modifying android setup script and Running it Open ~/imx-p9.0.0_2.0.0-ga/imx_android_setup.sh and add a line like below: ... ... if [ "$rc" != 0 ]; then echo "---------------------------------------------------" echo "-----Repo Init failure" echo "---------------------------------------------------" return 1 fi find -name 'aosp-p9.0.0_2.0.0-ga.xml'| \ xargs perl -pi -e 's|https://android.googlesource.com/|https://aosp.tuna.tsinghua.edu.cn/|g' fi ... ... Then save it and exit. # cd ~/ # source ~/imx-p9.0.0_2.0.0-ga/imx_android_setup.sh Then android_build directory is created at ~/ If fetching errors occur, like below, run “repo sync” again. # repo sync # export MY_ANDROID=~/android_build [Note] imx_android_setup.sh will be in charge of downloading all android source code. 5.Begin to compile android 9.0.0-2.0.0 BSP $ export ARCH=arm64 $ export CROSS_COMPILE=${MY_ANDROID}/prebuilts/gcc/linuxx86/aarch64/aarch64-linuxandroid-4.9/bin/aarch64-linux-android- $ cd ~/android_build/vendor $ cp -r ~/imx-p9.0.0_2.0.0-ga/vendor/* ./ $ cd ~/android_build $ source build/envsetup.sh $ lunch evk_8mm-userdebug $ make –j4 NXP TIC team Weidong sun 2019-05-05

INTRODUCTION REQUIREMENTS HARDWARE CONNECTIONS IMPLEMENTATION FUNCTIONAL DEMONSTRATION     1. INTRODUCTION   This document explains how to establish communication between the A9 core running Linux and the M4 core running an Arduino sketch on a UDOO NEO board to remotely control a robotic arm over Wi-Fi.   Figure 1: UDOO NEO board connected to the robotic arm   For more information about getting started with UDOO NEO board please refer to: Introduction - UDOO Neo Docs     2. REQUIREMENTS a) UDOO NEO board with UDOObuntu image and proper connectivity. The Linux image used is UDOObuntu 2 RC1 or RC2 (Ubuntu 14.04), available for download from the following link:      ARM Development Boards | Extended Support from UDOO For creating a bootable SD card and other basic setup please refer to the following guidelines:      Very First Start - UDOO Neo Docs Then, it is required to install the proper drivers to ensure connectivity, including USB communication with Linux terminal of the target board. Please refer to the link below:      Usb Direct Connection - UDOO Neo Docs b) The robotic arm itself. In this case, the used arm has four servomotors: three for articulation and one for open/close the clamp. c) A Wi-Fi router, and an additional Wi-Fi device with any SSH client application for the remote control of the arm.     3. HARDWARE CONNECTIONS   a) The first connection to consider is the USB Direct connection of the UDOO NEO board with the host PC, in order to configure the Wi-Fi network and remotely view of the desktop (VNC client) for Arduino sketch programming.   b) Then, it is required to consider the arm connection, which consists of four servomotors. Therefore, the motors must be powered by a separate power supply and controlled by four PWM signals. In this case, they will be connected to PWM_1, PWM_2, PWM_3 and PWM_4 signals of J4 connector (Arduino signals). Figure 2 shows the mentioned connection:   Figure 2: Servomotors connection to UDOO NEO board.     4. IMPLEMENTATION   4.1 Connecting to a Wi-Fi network. After turning on the UDOO NEO board, the USB Direct connection will install a virtual NIC on the host PC, in order to access to the “Dashboard”, a configuration webpage loaded on the NEO board that could be viewed from any web browser at address 192.168.7.2. You can connect to wireless networks by using the Web Control Panel, in Configuration/Network settings. After establishing connection with the Wi-Fi router, the Dashboard must indicate the assigned IP address of the NEO board as indicated on Figure 3. It is important to remember such address in order to establish the wireless access to the NEO board later (optionally, the NEO could be configured for a static IP address, or the router could be configure to assign the same IP address to the NEO board).   Figure 3: Dashboard showing the IP address of the NEO board.   Now the USB direct connection could be removed, as the Dashboard, remote terminal and VNC server are also available over Wi-Fi using the Wi-Fi IP address.   4.2. Programming the Arduino sketch. The remote desktop of the NEO could be viewed with any VNC client on the host PC, indicating the NEO’s IP address, user and password (same as SSH remote Terminal). The UDOObuntu image already include Arduino IDE configured for UDOO NEO board, so it is just required opening it to start writing the code. Figure 3 shows the UDOO NEO Desktop, which includes a Terminal window and the Arduino IDE. The sketch is available as attachment.   Figure 4: Desktop of UDOO NEO board.   4.3. Arduino sketch functionality. The Arduino program starts waiting for any incoming data over the serial port. After receiving any serial data, the four servomotors are initialized to the default position (90°). The serial port communication is established between a virtual serial port on Arduino side (Serial0), and the virtual serial port for the Multi-Core Communication (ttyMCC), like shown on Figure 5. For additional information please refer to the link below: Communication - UDOO Neo Docs Figure 5: Communication between cores. Once the motors are initialized, each movement is defined by a key to increase and decrease the angle position of the motors, except for the clamp, which is adjusted to open/close positions. Keys 'Q' and 'W' adjust the first motor; keys 'A' and 'S' adjust the second motor; keys 'D' and 'F' adjust the third motor, and finally, keys 'Z' and 'X' are used to open/close the clamp. Additionally, key 'R' resets all motors to default positions; key 'C' is used to enable/disable the PWM signals, and key 'V' prints the angle values of all motors. The adjust step of motors is defined with the macro “ANGLE_STEP”; the units are degrees.     5. FUNCTIONAL DEMONSTRATION   For demonstrative functionality, the UDOO NEO board running the Arduino sketch was connected to a Wi-Fi network, and it is also connected to the same network an Android phone with SSH app used to control the robotic arm. Figure 6 shows a screen capture of the mentioned app controlling the robotic arm. Figure 6: SSH app accessing to UDOO NEO.   Finally, the following video shows the functionality of the application:   Original Attachment has been moved to: robo_arm.ino.zip

Here is a quick summary at building a bootloader, a kernel and a root filesystem for the i.MX 6 sabre sd platform, using buildroot. This assumes you have a "working" Linux development environment at hand (e.g. Debian). Buildroot is a fine build system, which makes deploying Linux on embedded platforms really easy. It is comparable to Yocto in spirit, but much simpler. Thanks to my colleague gillestalis, buildroot now has builtin support for the i.MX6 sabre sd platform. Get buildroot sources We will use git to fetch buildroot sources: $ git clone git://git.busybox.net/buildroot This should create a buildroot directory with all the latest sources (after a while). Note that for more stability you might want to checkout a release instead of the latest version; to do so, list the available release tags with e.g. git tag -l '201*', and git checkout <the-desired-tag>. Compile The beauty of buildroot is that it will take care of everything for you, including preparing a cross compiler. You can download and build everything by doing: $ cd buildroot $ make freescale_imx6sabresd_defconfig $ make This should download and build everything, so it will take a while. buildroot detects the number of CPUs you have in your machine and builds with parallel jobs automatically; no need to specify any -j argument to make here. All build results fall under the output/images folder: output/images/ +- rootfs.ext2 +- rootfs.tar +- u-boot.bin `- uImage Format the SD card As for Debian, we need to format the SD card with two partitions; one small FAT partition to contain the Linux kernel, and one large ext4 partition, which will contain the root filesystem with the buildroot generated userspace. Also, we need to make sure we leave some space for u-boot starting from offset 1024B. Here is an example SD card layout: +-----+------+--------+-----+---------------+----------------- | MBR |  ... | u-boot | ... | FAT partition | Linux partition ... +-----+------+--------+-----+---------------+----------------- 0     512    1024           1M              ~257M (offsets in bytes) Here is an example SD card layout, as displayed by fdisk: Device    Boot      Start         End      Blocks   Id  System /dev/sdc1            2048      526335      262144    c  W95 FAT32 (LBA) /dev/sdc2          526336     8054783     3764224   83  Linux (units: 512B sectors) You can format the FAT boot partition with: # mkfs.vfat /dev/<your-sd-card-first-partition> Your SD card first partition is typically something in /dev/sd<X>1 or/dev/mmcblk<X>p1. You can format the Linux partition with: # mkfs.ext4 /dev/<your-sd-card-second-partition> Your SD card second partition is typically something in /dev/sd<X>2 or/dev/mmcblk<X>p2. Put on SD As explained here, u-boot should reside at offset 1024B of your SD card. Also, as buildroot generates an u-boot.bin (and not an u-boot.imx) we should skip its first KB, too. In summary, to put u-boot on your SD, do:   # dd if=output/images/u-boot.bin of=/dev/<your-sd-card> bs=1k seek=1 skip=1   # sync Your SD card device is typically something in /dev/sd<X> or /dev/mmcblk<X>. Note that you need write permissions on the SD card for the command to succeed, so you might need to su - as root, or use sudo, or do a chmod a+w as root on the SD card device node to grant permissions to users. Similarly to what this post describes, you can copy the kernel to the FAT boot partition with: # mount /dev/<your-sd-card-second-partition> /mnt # cp output/images/uImage /mnt/ # umount /mnt Your SD card first partition is typically something in /dev/sd<X>1 or/dev/mmcblk<X>p1. And not unlike what is done in this post, You can install your generated root filesystem to the Linux partition with: # mount /dev/<your-sd-card-second-partition> /mnt # tar -C /mnt -xvf output/images/rootfs.tar # umount /mnt Your SD card second partition is typically something in /dev/sd<X>2 or/dev/mmcblk<X>p2. Boot! Your SD card is ready for booting. Insert it in the SD card slot of your i.MX6 sabre sd platform, connect to the USB to UART port with a serial terminal set to 115200 baud, no parity, 8bit data and power up the platform. Like with Debian, u-boot default settings will not allow it to boot from the SD card, so we need to interrupt it by pressing enter at u-boot prompt for the first boot and setup u-boot environment to fix this: MX6Q SABRESD U-Boot > setenv bootargs_mmc 'setenv bootargs ${bootargs} root=/dev/mmcblk1p2 rootwait' MX6Q SABRESD U-Boot > setenv bootcmd_mmc 'run bootargs_base bootargs_mmc; mmc dev 2; fatload mmc 2:1 ${loadaddr} ${kernel}; bootm' MX6Q SABRESD U-Boot > setenv bootcmd 'run bootcmd_mmc' MX6Q SABRESD U-Boot > saveenv Saving Environment to MMC... Writing to MMC(2)... done As this is saved in the SD card it need only to be done once at first boot. You can reboot your board or type boot; your buildroot system should boot to a prompt: (...) Welcome to Buildroot buildroot login: From there you may login as root. Enjoy! Tweak buildroot uses Linux kernel kconfig to handle its configuration. So, as for the Linux kernel, changes to the configuration can be done with e.g.: $ make menuconfig Most of the options can be tuned from there, including (most importantly) which packages get installed into the generated root filesystem. This is configuration section 'Filesystem images'. Further details are documented in buildroot manual. Tips ccache is natively supported by buildroot and can be easily enabled with configuration option BR2_CCACHE. If you only use the generated rootfs.tar as described in this post and do not care about the rootfs.ext2, you might as well save a few seconds of build by disabling its generation. This is done with configuration option BR2_TARGET_ROOTFS_EXT2. It is recommended to install an ssh server inside the target for further development. This is conveniently done with configuration option BR2_PACKAGE_OPENSSH. See also... Other root filesystems may make more sense for you; see this post for a Debian root filesystem, and this post for a minimal busybox filesystem. Freescale Yocto Project main page

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

Question: When working with v1.6.0.55 using the standard profile for i.MX35 the tool fails most of the time when transferring the target root file system, on v1.6.0.42 it works just fine. The tags on the internal git don’t clearly mention a tool version, but a BSP. Wwhat are the differences between v1.6.0.55 and v1.6.0.42? Or to which tag(or commit) they correspond on git? Answer: 1.6.042 commit by looking at "Apps/MfgTool.exe/docs/changelog.txt": 1ca2a16df736ac51979a67423fef6a09bed6b7e2 And 1.6.055: "06a4f9190e34297b7273fc4bb4a92737e5bc837f"

///////////////////////////create device node /dev/galcore///////////////////////////// $home/myandroid/kernel_imx/drivers/mxc/gpu-viv/Kbuild MODULE_NAME ?= galcore /* define node name*/ $home/myandroid/kernel_imx/drivers/mxc/gpu-viv/hal/os/linux/kernel/gc_hal_kernel_linux.h define DEVICE_NAME "galcore" $home/myandroid/kernel_imx/drivers/mxc/gpu-viv/hal/os/linux/kernel/gc_hal_kernel_probe.c drv_init call ret = register_chrdev(major, DEVICE_NAME, &driver_fops); ///////////////////////////////opengles2 functios/////////////////////////////////////////// myandroid/device/fsl-proprietary/gpu-viv/lib/egl/libGLESv2_VIVANTE.so glActiveTexture glBindBuffer ... ... ... //those glxxxxxx call into sub_D40C int __fastcall sub_D40C(int a1, int a2, int a3) //address 0x0000D40C { int result; // r0@1 int v4; int v5; v4 = a2;   v5 = a3;   gcoOS_GetTLS(&v4);  //------------> goto libGAL.so   result = v4;   if ( v4 )     result = *(_DWORD *)(v4 + 36);   return result; } and $home/myandroid/device/fsl-proprietary/gpu-viv/lib/libGAL.so //export function signed int __fastcall gcoOS_GetTLS(void **a1) { ... ... gcoOS_GetTLS v4 = open("/dev/galcore", 2); ... ... } and device node /dev/galcore pass command into module galcore $home/myandroid/kernel_imx/drivers/mxc/gpu-viv/hal/kernel/gc_hal_kernel.c gckKERNEL_Dispatch This document was generated from the following discussion: Share Vivante 3d gc2000 work flow

If you cannot access the www.youtube.com, you may watch the citrix demo in Youku, the link as fellow: Citrix Receiver for Linux is a software client to access the desktops, applications, and data easily and securely from many types of Linux devices. About Installing Citrix Receiver,please go to Citrix website Receiver The i.MX 6DQ processor incorporates the hardware accelerators Video Processing Unit(VPU) and 3D/2D Graphics Processing Unit. By taking the advantage of i.MX 6DQ hardware accelerators, Freescale integrates H264 hardware decoder to Citrix Receiver for Linux on i.MX6DQ Ubuntu. With accelerated hardware decoding, the computing is offloaded and better performance is achieved. Configuration in the demo: Hardware i.MX6Q: i.MX 6Quad Processors: Quad Core, ARM® Cortex®-A9 Core 1920x1080 HDMI panel Software: Linux kernel 3.0.35 Ubuntu 12.04 hardfloat rootfs Citrix Receiver13.1 with Freescale H264 plug-in

Recently, I was asked about software/hardware floating point support on i.MX6. There are some great articles on the freescale community already but lacks of introduction. This document shares some basic knowledge on it. VFP is ARM's "Vector Floating Point" unit. SIMD operations can be better performed on several FPU extensions provided by ARM (NEON as in Cortex-A8 and Cortex-A9) [1]. To test if hardware floating support on freescale's toolchain, I used a simple application below: $ cat haha.c #include <stdio.h>; int main() {         float a = 0.3f, b=1.2f;         printf("%f\n", a * b);         return 0; } Compile it as below, and got the hardware floating point enabled. $ arm-linux-gcc -march=armv7-a -mfpu=neon -mfloat-abi=hard -o haha haha.c This can be checked by readelf. If Tag_ABI_VFP_args[2] shows VFP, it is hard floating. Otherwise, soft floating. $ arm-linux-readelf -A haha Attribute Section: aeabi File Attributes   Tag_CPU_name: "7-A"   Tag_CPU_arch: v7   Tag_CPU_arch_profile: Application   Tag_ARM_ISA_use: Yes   Tag_THUMB_ISA_use: Thumb-2   Tag_FP_arch: VFPv3   Tag_ABI_PCS_wchar_t: 4   Tag_ABI_FP_denormal: Needed   Tag_ABI_FP_exceptions: Needed   Tag_ABI_FP_number_model: IEEE 754   Tag_ABI_align_needed: 8-byte   Tag_ABI_align_preserved: 8-byte, except leaf SP   Tag_ABI_enum_size: int   Tag_ABI_HardFP_use: SP and DP   Tag_ABI_VFP_args: VFP registers   Tag_DIV_use: Not allowed Compared to the one by not specifying floating, compiler use soft floating by default, $ arm-linux-gcc -o haha_soft haha.c And readelf won't have Tag_ABI_VFP_args. $ arm-linux-readelf -A haha_soft Attribute Section: aeabi File Attributes   Tag_CPU_name: "ARM10TDMI"   Tag_CPU_arch: v5T   Tag_ARM_ISA_use: Yes   Tag_THUMB_ISA_use: Thumb-1   Tag_ABI_PCS_wchar_t: 4   Tag_ABI_FP_denormal: Needed   Tag_ABI_FP_exceptions: Needed   Tag_ABI_FP_number_model: IEEE 754   Tag_ABI_align8_needed: Yes   Tag_ABI_align8_preserved: Yes, except leaf SP   Tag_ABI_enum_size: int   Tag_unknown_44: 1 (0x1) [1]: https://wiki.debian.org/ArmHardFloatPort/VfpComparison [2]: For more detail on the Tag expression, check http://infocenter.arm.com/help/topic/com.arm.doc.ihi0045d/IHI0045D_ABI_addenda.pdf

You already know. Your source code is one week old now, so please, update it! $ repo sync What was the changes? Please, read the output and determinate what file was changed. Directory tree This is what I have under fsl-community-bsp directory: $ tree -d -L 2 -A . ├── build_mx53 │   ├── conf │   ├── sstate-cache │   └── tmp ├── build_mx6 │   ├── conf │   ├── sstate-cache │   └── tmp ├── downloads │   └── git2 └── sources     ├── base     ├── meta-fsl-arm     ├── meta-fsl-arm-extra     ├── meta-fsl-demos     ├── meta-openembedded     └── poky Sstate-cache keeps the pre-build packages cache so once one package is built, and it´s not changes, no need to re-build it again. If a team shares the same build environment, the sstate-cache folder can be shared as well. I´m not personally used to configure it, so, please, follow the doc: Yocto Project Reference Manual The downloads folder is shared for any build folder. It holds every package´s source code. For example, the ssh source code (and this source code can be built for any architecture) In addition, you may want to share the download folder with your team (one download folder for the complete team), so please, go to Yocto Project Reference Manual and look for DL_DIR. Build_mx6 tree .../build_mx6$ tree -d -L 2 -A . ├── conf ├── sstate-cache └── tmp     ├── buildstats     ├── cache     ├── deploy     ├── log     ├── pkgdata     ├── sstate-control     ├── stamps     ├── sysroots     ├── work     └── work-shared Inside tmp folder you will find images and build results. Images is placed inside deploy. Build statistics like initial and final time for each package/task are under buildstats The complete log for any 'bitbake' you did is under log. Take a look, for example, on the file  log/cooker/imx6qsabresd/11111111111.log. Please, notice that 111111111 is the PID number, so every time you run bitbake you have a different one. The source code, the patches, and the logs for the last bitbake, for each package is under work. Take a look on the files under tmp/work/imx6qsabresd-poky-linux-gnueabi/linux-imx/3.0.35-r37.14/ for example, for the kernel. .../build_mx6$ tree -d -L 1 -A tmp/work/imx6qsabresd-poky-linux-gnueabi/linux-imx/3.0.35-r37.14/ tmp/work/imx6qsabresd-poky-linux-gnueabi/linux-imx/3.0.35-r37.14/ ├── deploy-linux-imx ├── deploy-rpms ├── git ├── image ├── license-destdir ├── package ├── packages-split ├── pkgdata ├── pseudo ├── sysroot-destdir └── temp Go under temp, and see a lot of log.* and run.*: .../build_mx6$ ls tmp/work/imx6qsabresd-poky-linux-gnueabi/linux-imx/3.0.35-r37.14/temp/ log.do_bundle_initramfs             log.do_uboot_mkimage                run.do_package_write_rpm.28992      run.perform_packagecopy.16364 log.do_bundle_initramfs.28986       log.do_uboot_mkimage.2325           run.do_patch                        run.populate_packages.16364 log.do_compile                      log.do_unpack                       run.do_patch.2556                   run.read_shlibdeps.16364 log.do_compile.3483                 log.do_unpack.1155                  run.do_populate_lic                 run.read_subpackage_metadata.28992 log.do_compile_kernelmodules        log.task_order                      run.do_populate_lic.10988           run.split_and_strip_files.16364 log.do_compile_kernelmodules.29051  run.base_do_fetch.28859             run.do_populate_sysroot             run.split_kernel_module_packages.16364 log.do_configure                    run.base_do_unpack.1155             run.do_populate_sysroot.17692       run.split_kernel_packages.16364 log.do_configure.3048               run.BUILDSPEC.28992                 run.do_qa_configure.3048            run.sstate_create_package.10988 log.do_deploy                       run.debian_package_name_hook.16364  run.do_qa_staging.17692             run.sstate_create_package.16364 log.do_deploy.617                   run.do_bundle_initramfs             run.do_sizecheck                    run.sstate_create_package.17692 log.do_fetch                        run.do_bundle_initramfs.28986       run.do_sizecheck.2323               run.sstate_create_package.2724 log.do_fetch.28859                  run.do_compile                      run.do_strip                        run.sstate_create_package.28992 log.do_install                      run.do_compile.3483                 run.do_strip.2321                   run.sstate_create_package.617 log.do_install.2327                 run.do_compile_kernelmodules        run.do_uboot_mkimage                run.sstate_task_postfunc.10988 log.do_package                      run.do_compile_kernelmodules.29051  run.do_uboot_mkimage.2325           run.sstate_task_postfunc.16364 log.do_package.16364                run.do_configure                    run.do_unpack                       run.sstate_task_postfunc.17692 log.do_packagedata                  run.do_configure.3048               run.do_unpack.1155                  run.sstate_task_postfunc.2724 log.do_packagedata.2724             run.do_deploy                       run.emit_pkgdata.16364              run.sstate_task_postfunc.28992 log.do_package_write_rpm            run.do_deploy.617                   run.fixup_perms.16364               run.sstate_task_postfunc.617 log.do_package_write_rpm.28992      run.do_fetch                        run.package_depchains.16364         run.sstate_task_prefunc.10988 log.do_patch                        run.do_fetch.28859                  run.package_do_filedeps.16364       run.sstate_task_prefunc.16364 log.do_patch.2556                   run.do_install                      run.package_do_pkgconfig.16364      run.sstate_task_prefunc.17692 log.do_populate_lic                 run.do_install.2327                 run.package_do_shlibs.16364         run.sstate_task_prefunc.2724 log.do_populate_lic.10988           run.do_package                      run.package_do_split_locales.16364  run.sstate_task_prefunc.28992 log.do_populate_sysroot             run.do_package.16364                run.package_fixsymlinks.16364       run.sstate_task_prefunc.617 log.do_populate_sysroot.17692       run.do_packagedata                  run.package_get_auto_pr.16364       run.sysroot_cleansstate.3048 log.do_sizecheck                    run.do_packagedata.2724             run.package_get_auto_pr.2327        run.sysroot_stage_all.17692 log.do_sizecheck.2323               run.do_package_qa.16364             run.package_get_auto_pr.617         run.write_specfile.28992 log.do_strip                        run.do_package_rpm.28992            run.package_name_hook.16364 log.do_strip.2321                   run.do_package_write_rpm            run.patch_do_patch.2556 For each package, you will be able to see the log for the latest task, and what was done on the latest task. For example: log.do_compile - shows the log output from latest do_compile made for kernel run.do_compile - shows the compile command line log.do_compile.111111 - shows the log output from 1111111 time of do_compile In order to know the tasks and the task sequence, take a look to log.taskorder file For the images generated, you will find something like that: .../build_mx6$ ls -la tmp/deploy/images/imx6qsabresd/ total 146260 drwxr-xr-x 2 user user     4096 Mar  6 21:21 . drwxrwxr-x 3 user user     4096 Mar  6 21:12 .. -rw-r--r-- 1 user user 67108864 Mar  6 21:21 core-image-base-imx6qsabresd-20140306173758.rootfs.ext3 -rw-r--r-- 1 user user 83886080 Mar  6 21:21 core-image-base-imx6qsabresd-20140306173758.rootfs.sdcard -rw-r--r-- 1 user user 18782361 Mar  6 21:21 core-image-base-imx6qsabresd-20140306173758.rootfs.tar.bz2 lrwxrwxrwx 1 user user       55 Mar  6 21:21 core-image-base-imx6qsabresd.ext3 -> core-image-base-imx6qsabresd-20140306173758.rootfs.ext3 lrwxrwxrwx 1 user user       57 Mar  6 21:21 core-image-base-imx6qsabresd.sdcard -> core-image-base-imx6qsabresd-20140306173758.rootfs.sdcard lrwxrwxrwx 1 user user       58 Mar  6 21:21 core-image-base-imx6qsabresd.tar.bz2 -> core-image-base-imx6qsabresd-20140306173758.rootfs.tar.bz2 -rw-rw-r-- 2 user user   439697 Mar  6 21:12 modules--3.0.35-r37.14-imx6qsabresd-20140306173758.tgz lrwxrwxrwx 2 user user       54 Mar  6 21:12 modules-imx6qsabresd.tgz -> modules--3.0.35-r37.14-imx6qsabresd-20140306173758.tgz -rw-rw-r-- 2 user user      294 Mar  6 21:20 README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt lrwxrwxrwx 2 user user       35 Mar  6 21:16 u-boot.imx -> u-boot-imx6qsabresd-v2013.10-r0.imx lrwxrwxrwx 2 user user       35 Mar  6 21:16 u-boot-imx6qsabresd.imx -> u-boot-imx6qsabresd-v2013.10-r0.imx -rwxr-xr-x 2 user user   297984 Mar  6 21:16 u-boot-imx6qsabresd-v2013.10-r0.imx lrwxrwxrwx 2 user user       53 Mar  6 21:12 uImage -> uImage--3.0.35-r37.14-imx6qsabresd-20140306173758.bin -rw-r--r-- 2 user user  4042496 Mar  6 21:12 uImage--3.0.35-r37.14-imx6qsabresd-20140306173758.bin lrwxrwxrwx 2 user user       53 Mar  6 21:12 uImage-imx6qsabresd.bin -> uImage--3.0.35-r37.14-imx6qsabresd-20140306173758.bin You can access any generated image, the image name ending with the yearmothdaypid (long number) is the real image, and every time your bitbake complete, it generate a new image. The symbolic link points to the latest created image. The .ext3 file is the EXT3 image for the rootfs. (you can copy it directly to SD card using dd: $sudo dd if=core-image-base.ext3 of=/dev/sdb2 ) The .sdcard file is the complete image to be copied to sdcard. It´s u-boot+uImage+rootfs The .tar.bz2 file is the tarball for the rootfs, you can extract it on your PC. uImage is the latest kernel image u-boot is the latest u-boot image. and so on. Play around with generated files. A lot of them I don´t know. And a lot of them I don´t use. For a standard image generation you only need to know where the final images is placed. Any question, comment, issue, please let me know. Before you go, let your bitbake creates the biggest image ever: $ bitbake fsl-image-gui Note (24Feb2014): Required disk space for build image is ~44GB Start it and let it finish while you do something else. Go HOME Go to Task #2 Go to Task#4

Introduction This document describes the Spread Spectrum support for displays on i.MX 8QuadMax and i.MX 8QuadXPlus, specific for LVDS display. It describes the underlying HW function, how to enable it and the intended capability. The display controller (DC) subsystem on i.MX 8QuadMax and i.MX 8QuadXPlus uses an AVPLL to generate the reference clock for operation of the LVDS PHYs.  Enabling Spread Spectrum on the reference clock will result in the PHY interfaces being spread as well. This Spread Spectrum feature is controlled by the SCU firmware and can be enabled or disabled by configuring the board file of the SCU firmware porting kit. (The Spread Spectrum feature is added starting from SCFW porting kit V1.2.2 release which can be download from NXP web site “i.MX Software and Development Tool”.) The User Guide will include following content: 1. Introduction ............................................................................ 1 2. Configuration of the frequency modulation ......................... 2 3. Support in SCFW Porting Kit ............................................... 4 4. Modulation Characteristics ................................................... 4 5. Enablement Example ............................................................. 5 6. Revision History .................................................................... 7 For more information, please check the attachment "User Guide of Spread Spectrum for i.MX8QM_QXP Display.pdf".   Rev2.0 Update For SCFW Porting Kit V1.2.5 and later version, please check document "User Guide of Spread Spectrum for i.MX8QM_QXP Display 2.0.pdf" with updated algorithm. Rev2.1 Update For SCFW Porting Kit V1.2.10 and later version, please check document "User Guide of Spread Spectrum for i.MX8QM_QXP Display 2.1.pdf" with fspread value selection feature. Users can choose the percentage of frequency spread from following values: 0%, 0.4%, 1.0%, 1.4%, 2.0%.