The Linux L4.14.98_1.0.0_GA; and SDK2.5 for 8QM/8QXP Post GA, SDK2.5.1 for 7ULP GA3 release are now available. Linux on IMX_SW web page, Overview -> BSP Updates and Releases -> Linux L4.14.98_2.0.0 SDK on https://mcuxpresso.nxp.com Files available: Linux:  # Name Description 1 imx-yocto-L4.14.98_2.0.0_ga.zip L4.14.98_2.0.0 for Linux BSP Documentation. Includes Release Notes, User Guide. 2 L4.14.98_2.0.0_ga_images_MX6QPDLSOLOX.zip i.MX 6QuadPlus, i.MX 6Quad, i.MX 6DualPlus, i.MX 6Dual, i.MX 6DualLite, i.MX 6Solo, i.MX 6Solox Linux Binary Demo Files 3 L4.14.98_2.0.0_ga_images_MX6SLLEVK.zip i.MX 6SLL EVK Linux Binary Demo Files 4 L4.14.98_2.0.0_ga_images_MX6UL7D.zip i.MX 6UltraLite EVK, 7Dual SABRESD, 6ULL EVK Linux Binary Demo Files 5 L4.14.98_2.0.0_ga_images_MX7DSABRESD.zip i.MX 7Dual SABRESD Linux Binary Demo Files  6 L4.14.98_2.0.0_ga_images_MX7ULPEVK.zip i.MX 7ULP EVK Linux Binary Demo Files  7 L4.14.98_2.0.0_ga_images_MX8MMEVK.zip i.MX 8MMini EVK Linux Binary Demo Files  8 L4.14.98_2.0.0_ga_images_MX8MQEVK.zip i.MX 8MQuad EVK Linux Binary Demo files 9 L4.14.98_2.0.0_ga_images_MX8QMMEK.zip i.MX 8QMax MEK Linux Binary Demo files 10 L4.14.98_2.0.0_ga_images_MX8QXPMEK.zip i.MX 8QXPlus MEK Linux Binary Demo files 11 imx-scfw-porting-kit-1.2.tar.gz System Controller Firmware (SCFW) porting kit of L4.14.98_2.0.0 12 imx-aacpcodec-4.4.5.tar.gz Linux AAC Plus Codec v4.4.5 13 VivanteVTK-v6.2.4.p4.1.7.8.tgz Vivante Tool Kit v6.2.4.p4.1.7.8   SDK: On https://mcuxpresso.nxp.com/, click the Select Development Board, EVK-MCIMX7ULP//MEK-MIMX8QM/MEK-MIMX-8QX to customize the SDK based on your configuration then download the SDK package.  Target board: MX 8 Series MX 8QuadXPlus MEK Board MX 8QuadMax MEK Board MX 8M Quad EVK Board MX 8M Mini EVK Board MX 7 Series MX 7Dual SABRE-SD Board MX 7ULP EVK Board MX 6 Series MX 6QuadPlus SABRE-SD and SABRE-AI Boards MX 6Quad SABRE-SD and SABRE-AI Boards MX 6DualLite SDP SABRE-SD and SABRE-AI Boards MX 6SoloX SABRE-SD and SABRE-AI Boards MX 6UltraLite EVK Board MX 6ULL EVK Board MX 6ULZ EVK Board MX 6SLL EVK Board What’s New/Features: Please consult the Release Notes.   Known issues For known issues and more details please consult the Release Notes.   More information on changes of Yocto, see: README: https://source.codeaurora.org/external/imx/imx-manifest/tree/README?h=imx-linux-sumo ChangeLog: https://source.codeaurora.org/external/imx/imx-manifest/tree/ChangeLog?h=imx-linux-sumo#

         This document will describe how to add open JDK to i.MX yocto BSP. It will take two versions of Linux BSP as an example, one is the lower version of L4.1.15-2.0.0, the other is the latest version of L4.19.35-1.1.0. Adding openjdk-8 to L4.1.15-2.0.0(Ubuntu 16.04 LTS platform) Before adding an open JDK, you must download L4.1.15-2.0.0 BSP according to the i.MX_Yocto_Project_User's_Guide.pdf, and ensure that it can pass the compilation normally, that is to say, there is no error in the compilation. In this example, BSP is compiled using the following command. # DISTRO=fsl-imx-wayland MACHINE=imx6sxsabresd source fsl-setup-release.sh -b build-wayland # bitbake fsl-image-qt5          Then follow the steps below to add openjdk to the yocto layer:   Fetching openjdk-8 from Yocto website # cd ~/imx-release-bsp # cd sources # git clone git://git.yoctoproject.org/meta-java # cd meta-java # git checkout -b krogoth origin/krogoth  [Comment]    Yocto’s version is described in i.MX_Yocto_Project_User's_Guide.pdf 2. Modifying related configurations (1) build-wayland/conf/local.conf Add following lines to the file: # Possible provider: cacao-initial-native and jamvm-initial-native PREFERRED_PROVIDER_virtual/java-initial-native = "cacao-initial-native" # Possible provider: cacao-native and jamvm-native PREFERRED_PROVIDER_virtual/java-native = "cacao-native" # Optional since there is only one provider for now PREFERRED_PROVIDER_virtual/javac-native = "ecj-bootstrap-native" IMAGE_INSTALL_append = " openjdk-8" Save it and exit (2)build-wayland/conf/bblayers.conf Add java layer to the file, like below: BBLAYERS = " \   ${BSPDIR}/sources/poky/meta \   ${BSPDIR}/sources/poky/meta-poky \   \   ${BSPDIR}/sources/meta-openembedded/meta-oe \   ${BSPDIR}/sources/meta-openembedded/meta-multimedia \   \   ${BSPDIR}/sources/meta-fsl-arm \   ${BSPDIR}/sources/meta-fsl-arm-extra \   ${BSPDIR}/sources/meta-fsl-demos \   ${BSPDIR}/sources/meta-java \ "…… Save it and exit. 3. Build openjdk-8 # cd ~/imx-release-bsp # source setup-environment build-wayland #bitbake openjdk-8 -c fetchall          Fetch all packages related to openjdk-8. [error handling]          During downloading packages, you may encounter errors like the following. (1)Fetch fastjar-0.98.tar.gz errors          The error is caused by invalid web address, we can download it from another link, see below: http://savannah.c3sl.ufpr.br/fastjar/fastjar-0.98.tar.gz copy the link to firefox in Ubuntu platform, and it will be downloaded into ~/Downloads # cd ~/imx-release-bsp/downloads # cp ~/Downloads/ fastjar-0.98.tar.gz ./ # touch fastjar-0.98.tar.gz.done   (2)Fetch “classpath-0.93.tar.gz” error          Download it from : http://mirror.nbtelecom.com.br/gnu/classpath/classpath-0.93.tar.gz And copy it to ~/imx-release-bsp/downloads, and create a file named classpath-0.93.tar.gz.done in the directory. # cd ~/imx-release-bsp/downloads # cp ~/Downloads/ classpath-0.93.tar.gz ./ # touch classpath-0.93.tar.gz.done (3) 8 files with tar.bz2 (hotspot-Java jvm)          These similar errors are very likely to be encountered.          These errors are caused by the bad network environment. You can download these packages manually. These are Java virtual machine source packages, i.e. hotspot JVM [Solution] # mkdir ~/temp # cd temp # wget http://www.multitech.net/mlinux/sources/56b133772ec1.tar.bz2 # wget http://www.multitech.net/mlinux/sources/ac29c9c1193a.tar.bz2 # wget http://www.multitech.net/mlinux/sources/1f032000ff4b.tar.bz2 # wget http://www.multitech.net/mlinux/sources/81f2d81a48d7.tar.bz2 # wget http://www.multitech.net/mlinux/sources/0549bf2f507d.tar.bz2 # wget http://www.multitech.net/mlinux/sources/0948e61a3722.tar.bz2 # wget http://www.multitech.net/mlinux/sources/48c99b423839.tar.bz2 # wget http://www.multitech.net/mlinux/sources/bf0932d3e0f8.tar.bz2          Then create .tar.bz2.done files for each package via touch command   # touch 56b133772ec1.tar.bz2.done # touch ac29c9c1193a.tar.bz2.done # touch 1f032000ff4b.tar.bz2.done # touch 81f2d81a48d7.tar.bz2.done # touch 0549bf2f507d.tar.bz2.done # touch 0948e61a3722.tar.bz2.done # touch 48c99b423839.tar.bz2.done # touch bf0932d3e0f8.tar.bz2.done          Like below:          Then copy these files to ~/ fsl-release-bsp/downloads/ # bitbake openjdk-8 -c compile          After openjdk compilation, you will be prompted as follows:          At last , install openjdk-8 to images # bitbake fsl-image-qt5          Done: [Additional description]          The above method of adding openjdk-8 is the steps after BSP compilation. Users can also add openjdk-8 before BSP compilation, and then compile it with BSP          According to steps in i.MX_Yocto_Project_User's_Guide.pdf, After running the following two commands, users can modify bblayers.conf and local.conf directly.          For example, steps below have been validated: … … # repo sync # cd ~/fsl-release-bsp # DISTRO=fsl-imx-x11 MACHINE=imx6qsabresd source fsl-setup-release.sh -b build-x11 # gedit ./conf/bblayers.conf          Add the same contents as above. # gedit ./conf/local.conf          Add the same contents as above. # bitbake fsl-image-gui          During compilation, users may encounter some errors, which can be handled by referring to the methods described above Adding openjdk-8 to L4.19.35-1.1.0(Ubuntu 18.04 LTS Platform) In fact, the steps to add openjdk-8 to l4.19.35 are the same as those described above, and the following steps have been verified. Before adding openjdk-8, i.mx8qxp full image has been compiled with 2 commands below, so we only need to add openjdk-8 here. # DISTRO=fsl-imx-xwayland MACHINE=imx8qxpmek source fsl-setup-release.sh -b build-xwayland # bitbake imx-image-full # cd sources # git clone git://git.yoctoproject.org/meta-java # cd meta-java # git checkout -b warrior origin/warrior          Release L4.19.35_1.1.0 is released for Yocto Project 2.7 (Warrior). # cd ~/imx-release-bsp-l4.19.35 # source setup-environment build-xwayland-imx8qxpmek # gedit ./conf/bblayers.conf          Add meta-java to it.          ……            ${BSPDIR}/sources/meta-java \          ……          Save and exit. # gedit ./conf/local.conf          Add these lines to it.          # Possible provider: cacao-initial-native and jamvm-initial-native PREFERRED_PROVIDER_virtual/java-initial-native = "cacao-initial-native" # Possible provider: cacao-native and jamvm-native PREFERRED_PROVIDER_virtual/java-native = "cacao-native" # Optional since there is only one provider for now PREFERRED_PROVIDER_virtual/javac-native = "ecj-bootstrap-native" IMAGE_INSTALL_append = " openjdk-8" Save and exit.   # cd ~/imx-release-bsp-l4.19.35/build-xwayland-imx8qxpmek # bitbake openjdk-8 -c fetch # bitbake openjdk-8 -c compile [Errors] [Solution] # gedit ./ tmp/work/x86_64-linux/openjdk-8-native/172b11-r0/jdk8u-33d274a7dda0/hotspot/make/linux/Makefile Comment the following lines: ----------------------------------------- check_os_version: #ifeq ($(DISABLE_HOTSPOT_OS_VERSION_CHECK)$(EMPTY_IF_NOT_SUPPORTED),) #       $(QUIETLY) >&2 echo "*** This OS is not supported:" `uname -a`; exit 1; #endif -----------------------------------------          Then continue # cd ~/imx-release-bsp-l4.19.35/build-xwayland-imx8qxpmek # bitbake openjdk-8 -c compile [comment]          Probably similar errors will be encountered during compiling other packages, we can use the same way like above to solve it, see bellow, please! Done:          At last, install openjdk-8 to images. # bitbake imx-image-full          Installation is done. NXP TIC Team  Weidong Sun 12/31/2019

The i.MX Android N7.1.1_1.0.0 release is now available on Web Site (i.MX6 BSP Updates and Releases -> Android).   Files available: # Name Description 1 android_N7.1.1_1.0.0_docs.tar.gz i.MX Android N7.1.1_1.0.0 BSP Documentation 2 android_N7.1.1_1.0.0_source.tar.gz Source Code of Android N7.1.1_1.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.1_1.0.0_image_6dqpsabreauto.tar.gz Binary Demo Files of Android N7.1.1_1.0.0 BSP - SABRE for Automotive Infotainment based on i.MX 6QuadPlus, i.MX 6Quad, and i.MX 6DualLite 4 android_N7.1.1_1.0.0_image_6dqpsabresd.tar.gz Binary Demo Files of Android N7.1.1_1.0.0 BSP - SABRE Platform and SABRE Board based on i.MX 6QuadPlus, i.MX 6Quad and i.MX 6DualLite. 5 android_N7.1.1_1.0.0_image_6slevk.tar.gz Binary Demo Files of Android N7.1.1_1.0.0 BSP - i.MX 6Sololite evaluation kit. 6 android_N7.1.1_1.0.0_image_6sxsabresd.tar.gz Binary Demo Files of Android N7.1.1_1.0.0 BSP - SABRE Board based on i.MX 6SoloX 7 android_N7.1.1_1.0.0_image_6sxsabreauto.tar.gz Binary Demo Files of Android N7.1.1_1.0.0 BSP - SABRE for Automotive infotainment based on i.MX 6SoloX 8 android_N7.1.1_1.0.0_image_7dsabresd.tar.gz Binary Demo Files of Android N7.1.1_1.0.0 BSP - SABRE Board based on i.MX 7Dual 9 android_N7.1.1_1.0.0_tools.tar.gz Manufacturing Toolkit and VivanteVTK for N7.1.1_1.0.0   Supported Hardware SoC/Boards: MX 6Quad, i.MX 6QuadPlus, and i.MX 6DualLite SABRE-SD board and platform MX 6Quad, i.MX 6QuadPlus, and i.MX 6DualLite SABRE-AI board and platform MX 6SoloLite EVK platform MX 6SoloX SABRE-SD board and platforms MX 6SoloX SABRE-AI board and platforms MX 7Dual SABRE-SD board and platform   Changes: Compared to the M6.0.1_2.1.0 release, this release has the following major changes: Upgraded the Android platform version to Android 7.1. Upgraded the U-Boot and Linux Kernel Code base from the L4.1.15_1.0.0 release to the L4.1.15_1.2.0-ga release. Added support for the i.MX 7Dual SABRE-SD board. Upgraded the GPU driver from 5.0.11p8 to 6.2.0.p2.   Feature: For features please consult the release notes.   Known issues For known issues and more details please consult the Release Notes.

The purpose of the document is to help customer setup development  environment of android BSP, The document includes the following contents: 1.Setup environment for compiling android BSP source code 2. Setup tftp and NFS environment for android development 3. Common Steps of Porting android  to customized borad ( L3.0.35 kernel) Note: (1) ubuntu version is suitable for 12.04/14.04/15.04 (2) android BSP version is 4.2.2 / 4.3 / 4.4.2  If cusotmer is using android5.1.1 / android 6.0 or above, The way of porting kernel should be focused on adjusting device tree. (3)Each andoid BSP has its own MFG tools version. User should pay attention to this, don't use wrong version of MFG Tools. NXP TIC team Weidong Sun

Some Chinese customers using i.MX series SoC maybe encounter some issues when they download android , u-boot & kernel source code by 'git' command, the following steps will show customer how to get them: 1. Getting repo --No.1 methord # cd ~ # mkdir myandroid # mkdir bin # cd bin # git clone git://aosp.tuna.tsinghua.edu.cn/android/git-repo.git/ <if git failed, use : git clone https://aosp.tuna.tsinghua.edu.cn/android/git-repo.git/> # cd git-repo # cp ./repo ../ --No.2 methord # cd ~ # mkdir bin # curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo # chmod a+x ~/bin/repo [Note]Customers can select one of above to get "repo" 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 = 'git://aosp.tuna.tsinghua.edu.cn/android/git-repo'        like following: ## repo default configuration ## REPO_URL = 'git://aosp.tuna.tsinghua.edu.cn/android/git-repo' REPO_REV = 'stable' 3、Setting email address # cd ~/myandroid # git config --global user.email "weidong.sun@nxp.com" # git config --global user.name "weidong.sun" [ Email & Name should be yours] 4、Getting manifest # ~/bin/repo init -u https://aosp.tuna.tsinghua.edu.cn/android/platform/manifest -b android-5.1.1_r1 # cd ~/myandroid/.repo # gedit manifest.xml        Then change the value of fetch to " git://aosp.tuna.tsinghua.edu.cn/android/ ", like following: <manifest>   <remote name="aosp"            fetch="git://aosp.tuna.tsinghua.edu.cn/android/" />   <default revision="refs/tags/android-5.1.1_r1" ...... [Note] android-5.1.1_r1 is version of branch,customer can change it to another. 5、# ~/bin/repo sync          [Note] During runing repo sync, maybe errors will occur like the following: ...... * [new tag]         studio-1.4 -> studio-1.4 error: Exited sync due to fetch errors          Then 'repo sync' exits. But don't worry about it, continue to run the command please ! " ~/bin/repo sync", downloading source code will be continous. 6、Getting Cross Compiler # cd ~/myandroid/prebuilts/gcc/linux-x86/arm # git clone https://aosp.tuna.tsinghua.edu.cn/android/platform/prebuilts/gcc/linux-x86/arm/arm-eabi-4.6 # cd arm-eabi-4.6 # git checkout android-4.4.3_r1 7、Getting linux kernel source code        Probably, customer can't normally get linux kernel by using "git clone" command, she can download it directly from the following weblink:        http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/        At first, create a temperary directory, then download kernel into the directory. see following steps: # cd ~ /Downloads # mkdir linux-kernel   Atfer downloading l5.1.1_2.1.0-ga.tar.gz, use 'tar zxvf l5.1.1_2.1.0-ga.tar.gz' command to decompress it.        Then you can find a subdirectory name " l5.1.1_2.1.0-ga" is created, linux source code is in the directory, we should copy all files in the directory to ~/myandroid/kernel_imx/ # cd ~/myandroid # mkdir kernel_imx # cd kernel_imx # cp -a ~ /Downloads/linux-kernel/l5.1.1_2.1.0-ga ./ 8、Getting uboot source code               Probably, customer can't normally get linux kernel by using "git clone" command, she can download it directly from the following weblink:       http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/        We can use similar way to that of linux kernel to get u-boot source code: # cd ~ /Downloads # mkdir u-boot        Download l5.1.1_2.1.0-ga.tar.gz file, and save it in ~ /Downloads/ u-boot, then decompress it, then u-boot source code will be in ~ /Downloads/ u-boot / l5.1.1_2.1.0-ga/, we should copy all file in the path to ~/myandroid/bootable/bootloader/uboot-imx/ # cd ~/myandroid/bootable/bootloader # mkdir uboot-imx # cd uboot-imx # cp -a ~ /Downloads/u-boot/l5.1.1_2.1.0-ga/* ./ 9、Patch android BSP source code        android_L5.1.1_2.1.0_consolidated-ga_core_source.gz is the name of patch. Run following command to patch android. # copy android_L5.1.1_2.1.0_consolidated-ga_core_source.gz /opt/ # tar zxvf android_L5.1.1_2.1.0_consolidated-ga_core_source.gz # cd /opt/ android_L5.1.1_2.1.0_consolidated-ga_core_source/code/ # tar zxvf L5.1.1_2.1.0_consolidated-ga.tar.gz # cd ~/myandroid # source /opt/ android_L5.1.1_2.1.0_consolidated-ga_core_source/code/ L5.1.1_2.1.0_consolidated-ga/ and_patch.sh # help # c_patch /opt/ android_L5.1.1_2.1.0_consolidated-ga_core_source/code/ L5.1.1_2.1.0_consolidated-ga/ imx_L5.1.1_2.1.0-ga        If everything is OK, the following logs will display on console:               **************************************************************        Success: Now you can build the Android code for FSL i.MX platform               ************************************************************** 10、Patch Freescale extended feathures code        Please refer to chapter 3.3 of Android_User's_Guide.pdf to patch another 2 files:        (1) android_L5.1.1_2.1.0_consolidated-ga_omxplayer_source.gz        (2) android_L5.1.1_2.1.0_consolidated-ga_wfdsink_source.gz [Note]       As for other steps, such as compiling etc, please refer to Android_User's_Guide.pdf that released by NXP. TICS team Weidong Sun 04/01/2016

A new version of the Pins Tool for i.MX Application Processors has been released and is available for download as desktop tool from Pins Tool for i.MX Application Processors|NXP. The pins Tool for i.MX Application Processors is used for pin routing configuration, validation and code generation, including pin functional/electrical properties, power rails, run-time configurations, with the following main features: Desktop application Muxing and pin configuration with consistency checking Multicore support ANSI-C initialization code Graphical processor package view Multiple configuration blocks/functions Easy-to-use device configuration Selection of Pins and Peripherals Package with IP blocks Routed pins with electrical characteristics Registers with configured and reset values Power Groups with assigned voltage levels Source code for C/C++ applications Documented and easy to understand source code CSV Report and Device Tree File Localized for English and Simplified Chinese Mostly Connected: On-Demand device data download Integrates with any compiler and IDE What's New Added Label support to give signals a name Added ‘Log’ and ‘Problems’ view to report conflicts between settings Added support for templates to store user configurations as starting point for new configurations Added ability to download and share data for devices, especially for off-network host machines i.MX header files are now automatically part of the device data Import of legacy Processor Expert .pe files Export of register defines Various bug fixes and documentation improvements The release notes of the desktop application are attached to this article. Import Processor Expert Files A new importer has been added to import legacy Processor Expert for i.MX files: Labels Signals can now have user defined labels: Templates, Kits, Boards and Processors When creating a new configuration, it offers Templates, Boards and Processors. Custom configurations can be stored as templates and then used for new configurations. Board Specific Functions With the provided board and kit configurations, there are now pre-configured initialization functions for major blocks on the board: Export Data To simplify downloading the device specific data for the desktop tool, the 'Export' function can be used to download and export the data. The data can be copied that way to another machine or all data for a set of devices can be loaded. Export Registers With the Export command the registers can be exported as text/source: This is used to store the register values: /*FUNCTION********************************************************************** * * Function Name : init_audmux_pins * Description   : Configures pin routing and optionally pin electrical features. * *END**************************************************************************/ #define INIT_AUDMUX_PINS_IOMUXC_AUD5_INPUT_DA_AMX_SELECT_INPUT_VALUE            0x00000000   /*!< Register name: IOMUXC_AUD5_INPUT_DA_AMX_SELECT_INPUT */ #define INIT_AUDMUX_PINS_IOMUXC_AUD5_INPUT_TXCLK_AMX_SELECT_INPUT_VALUE         0x00000000   /*!< Register name: IOMUXC_AUD5_INPUT_TXCLK_AMX_SELECT_INPUT */ #define INIT_AUDMUX_PINS_IOMUXC_AUD5_INPUT_TXFS_AMX_SELECT_INPUT_VALUE          0x00000000   /*!< Register name: IOMUXC_AUD5_INPUT_TXFS_AMX_SELECT_INPUT */ #define INIT_AUDMUX_PINS_IOMUXC_SW_MUX_CTL_PAD_DI0_PIN02_VALUE                  0x00000002   /*!< Register name: IOMUXC_SW_MUX_CTL_PAD_DI0_PIN02 */ #define INIT_AUDMUX_PINS_IOMUXC_SW_MUX_CTL_PAD_DI0_PIN03_VALUE                  0x00000002   /*!< Register name: IOMUXC_SW_MUX_CTL_PAD_DI0_PIN03 */ #define INIT_AUDMUX_PINS_IOMUXC_SW_MUX_CTL_PAD_DI0_PIN04_VALUE                  0x00000002   /*!< Register name: IOMUXC_SW_MUX_CTL_PAD_DI0_PIN04 */ #define INIT_AUDMUX_PINS_IOMUXC_SW_MUX_CTL_PAD_DI0_PIN15_VALUE                  0x00000002   /*!< Register name: IOMUXC_SW_MUX_CTL_PAD_DI0_PIN15 */ #define INIT_AUDMUX_PINS_IOMUXC_SW_MUX_CTL_PAD_DISP0_DATA16_VALUE               0x00000003   /*!< Register name: IOMUXC_SW_MUX_CTL_PAD_DISP0_DATA16 */ #define INIT_AUDMUX_PINS_IOMUXC_SW_MUX_CTL_PAD_DISP0_DATA18_VALUE               0x00000003   /*!< Register name: IOMUXC_SW_MUX_CTL_PAD_DISP0_DATA18 */ #define INIT_AUDMUX_PINS_IOMUXC_SW_MUX_CTL_PAD_DISP0_DATA19_VALUE               0x00000003   /*!< Register name: IOMUXC_SW_MUX_CTL_PAD_DISP0_DATA19 */ ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ We hope you will find this new release useful. Thanks for designing with NXP! 

This patch release is target for LPDDR2 ( dual channels in interleave mode ) support on i.MX6DL platform. Two patches are prepared to modify u-boot and kernel in order to have correct DRAM init sequence, 400MHz & 24MHz frequency switching and suspend/resume support. The patches are not fully verified. It is provided as reference for customer to enable their i.MX6DL board with LPDDR2. Customization and Testing is needed by customer. We need to remind some points here: MMDC_MDCFG3LP in 24MHz need to increase the margin ( 0x40222 -> 0x80555 ) in order to pass the OS frequency switch stress test. We are identifying the reason but this workaround is working fine and included to the patch. Code changes in kernel is prepared so that it is compatible to DDR3. In other words, the DDR type will be detected and a correct handling will be done for LPDDR2 and DDR3. In LPDDR2 system, we can't put SDQ pin into LPM during suspend. Otherwise, the system cannot resume. Dual channels in fix mapping mode is not recommended to use.

Uploading the i.MX 6 Linux Reference Manual here after being un-able to find it on Google or on i.MX6 product page.

Starting from $52, the VAR-SOM-MX6 sets the bar for unparalleled design flexibility. The VAR-SOM-MX6 ensures scalable and simplified development, while also extending the product lifecycle. Thanks to four CPU core assembly options, customers can apply a single System on Module in a broad range of applications to achieve short time-to-market for their current innovations, while still accommodating potential R&D directions and marketing opportunities.     VAR-SOM-MX6 CPU: Freescale iMX6 Key features include: Freescale i.MX6 1.2GHz Quad / Dual / Single core Cortex-A9       2GB DDR3, 1GB SLC NAND Flash       Full HD 1080p video encoding/decoding capability       Vivante GPU providing 2D/3D acceleration       Simultaneous multiple display support       Gigabit Ethernet       TI WiLink™ 6.0 single-chip connectivity solution (Wi-Fi, Bluetooth®)       PCI-Express 2.0, S-ATA 3.0       Camera interface       USB 2.0: Host, OTG       Audio In/Out       Dual CAN Bus This versatile solution's -40 to 85°C temperature range and Dual CAN support is ideal for industrial applications, while 1080p video and graphics accelerations make it equally suitable for intensive multimedia applications. The impressive scalability of the VAR-SOM-MX6 satisfies the needs of the most demanding future application requirements whether faster processing power, enhanced algorithms or improved graphics and video performance to name just a few. The VAR-SOM-MX6 is an all-round solution with broad connectivity and sophisticated video and acceleration graphic capabilities, delivering a range of middle to high end assembly options all from the same product. For more details, please see VAR-SOM-MX6 CPU: Freescale iMX6

Hi All, The new i.MX 6 Q/D/DL/S/SL L3.0.35_4.1.0 GA release is now available on the http://www.freescale.com/site. ·         Files available                                   # Name Description 1 L3.0.35_4.1.0_LINUX_DOCS i.MX   6Quad, i.MX 6Dual, i.MX 6DualLite, i.MX 6Solo and i.MX 6Sololite Linux BSP   Documentation. Includes Release Notes, Reference Manual, User guide. API   Documentation 2 L3.0.35_4.1.0_LINUX_MMDOCS i.MX   6Quad, i.MX 6Dual, i.MX 6DualLite, i.MX 6Solo and i.MX 6Sololite  Linux Multimedia Codecs Documentation.   Includes CODECs Release Notes and User's Guide 3 L3.0.35_4.1.0_SOURCE_BSP i.MX   6Quad, i.MX 6Dual, i.MX 6DualLite, i.MX 6Solo and i.MX 6Sololite Linux BSP   Source Code Files 4 L3.0.35_4.1.0_MM_CODECS i.MX   6Quad, i.MX 6Dual, i.MX 6DualLite, i.MX 6Solo and i.MX 6Sololite  Linux Multimedia Codecs Sources 5 L3.0.35_4.1.0_AACP_CODECS i.MX   6Quad, i.MX 6Dual, i.MX 6DualLite, i.MX 6Solo and i.MX 6Sololite  Linux AAC Plus Codec 6 L3.0.35_4.1.0_DEMO_IMAGE_BSP i.MX   6Quad, i.MX 6Dual, i.MX 6DualLite, i.MX 6Solo and i.MX 6Sololite  Linux Binary Demo Files 7 L3.0.35_4.1.0_UBUNTU_RFS_BSP i.MX   6Quad, i.MX 6Dual, i.MX 6DualLite, i.MX 6Solo and i.MX 6Sololite  Linux File System for the Ubuntu Images 8 i.MX_6D/Q_Vivante_VDK_146_Tools Set   of applications for the Linux L3.0.35_4.1.0 BSP, designed to be used by   graphics application developers to rapidly develop and port graphics   applications. Includes applications, GPU Driver with vprofiler enabled and   documentation. 9 IMX_6DL_6S_MFG_TOOL Tool   and documentation for downloading OS images to the i.MX 6DualLite and i.MX   6Solo. 10 IMX_6DQ_MFG_TOOL Tool   and documentation for downloading OS images to the i.MX 6Quad and i.MX 6Dual. 11 IMX_6SL_MFG_TOOL Tool   and documentation for downloading OS images to the i.MX 6Sololite. ·         Target HW boards o   i.MX 6Quad SABRE-SDP o   i.MX 6Quad SABRE-SDB o   i.MX 6Quad SABRE-AI o   i.MX 6DualLite SABRE-SDP o   i.MX 6DualLite SABRE-AI o   i.MX 6SL EVK ·         New features o   BSP New Features on i.MX 6D/Q, i.MX 6DL/S and MX 6SL: §  HDCP §  CEC §  GPU4.6.9p12 §  Audio playback IRAM/SDMA §  V4L capture resize on MX6SL §  MX6DQ disable the double line fill feature of PL310 ·         Known issues o   For known issues and limitations please consult the release notes.

The i.MX 6 D/Q/DL/S/SL Linux 3.10.17_1.0.0 GA release is now available on www.freescale.com Files available Name Description L3.10.17_1.0.0_LINUX_DOCS i.MX 6 D/Q/DL/S/SL Linux 3.10.17_1.0.0 GA BSP documentation. y L3.10.17_1.0.0_iMX6QDLS_Bundle i.MX 6 D/Q/DL/S  Linux 3.10.17_1.0.0 GA BSP Binary Demo Files L3.10.17_1.0.0_iMX6SL_Bundle i.MX 6 SL  Linux 3.10.17_1.0.0 GA BSP Binary Demo Files i.MX_6_Vivante_VDK_150_Tools Vivante VTK 1.5 Codec for the i.MX 6 D/Q/DL/S/SL Linux 3.10.17_1.0.0 GA BSP    y L3.10.17_1.0.0_AACP_CODECS AAC Plus Codec for the i.MX 6 D/Q/DL/S/SL Linux 3.10.17_1.0.0 GA BSP y IMX_6_MFG_L3.10.17_1.0.0_TOOL Manufacturing Tool and Documentation for Linux 3.10.17_1.0.0 GA BSP y Target HW boards o   i.MX6DL  SABRE SD board o   i.MX6Q  SABRE SD board o   i.MX6DQ SABRE AI board o   i.MX6DL SABRE AI board o   i.MX6SL EVK board New  Features o   Main BSP New Features on MX6DQ, MX6DL and MX6SL from L3.10.9_1.0.0 GA: SD3.0 reset USB HSIC HWRNG security feature on MX6SL VIIM OTP Fuse in uboot Battery charge LED U-boot USB mass storage support USB Camera on host mode X backend: Adaptive HDMI display support backed by XRandR Main Codec New Features on MX6DQ, MX6DL and MX6SL from L3.10.17_1.0.0 Beta: Bug fix Main Codec New Features on MX6DQ, MX6DL and MX6SL from L3.10.17_1.0.0 Beta: Bug fix Other features not supported found during testing: UART: only support some baud rates like 9600, 115200, can't support high to 4000000 Known issues For known issues and limitations please consult the release notes located in the BSP documentation package.

These questions and answers are about interrupt generation at a dedicated (configurable) video output port. The i.MX6D manual (Rev. 0) Image Processing Unit (IPU) chapter mentions: Every DI has 10 timing generator counters. The IPU Interrupt Generator has 10 DI0 counters (1...10) and just 2 DI1 counters (3 & 😎 as interrupt sources. The Interrupt Control Register lists 11 DI0 counters (0...10) Q1. Are the DI timing-generator counters linked to the counters in the interrupt controller, or are they different counters? A1. Yes, the DI timing generator counters are linked to the counters in the interrupt controller. Q2. Why are there 11 counters listed in the interrupt controller, but just 10 counters in the timing generator? A2. There is disp_clk_en_pre in the interrupt controller. Thus the 11 counters: 10 timing generator counters and 1 disp clock generator counter. Q3. Is configurable timing feasible for DI0 by using the timing generator counters? A3. Yes, using the 10 internal timing counters you can generate various timing relationships. In addition, you can detect any of the interrupt counters. For example, if you use counter 8, then you can detect the interrupt associated with counter 8. Q4. Explain the impact of the DI1 counter access of only channels 3 and 8. A4. DI1 also has 10 timing generator counters and 1 disp clock generator counter, which you can use to generate desired waveforms. This is similar to DI0. The difference is only 2 of the 10 counters (plus another disp_clk) are connected to the interrupt controller for DI1. Therefore, there is a restriction for detection. If you use counter 7, read out the counter 7 interrupt of DI1 is not possible. However, 2 channels should be sufficient. These interrupts are usually used to indicate a frame start or a frame end. We usually use counter 3 to represent Vsync. So normally we only use counter 3 interrupt. DI1 has only 3 accesses because this covers the anticipated use case and the desire was to restrict register size. The extra counters facilitate flexible DI1 timing generation.

The document includes the following contents: (1)document how to port ov5646 to android jb4.2.2 (2) ov5645 driver for Linux 3.0.35 (3) ov5645 schematic based on i.MX6Q/DL (4)ov5645 for android camera HAL   [Note:]      P5V29A-0JG is a camera module based on OV5645, and PAO532-0JG is based on OV5640, both manufactured by NINGBO SUNNY OPOTECH CO.LTD (China), If customer wants to use them on i.MX6 platform, can send me email to ask for datasheets of P5V29A & PAO532 , or discuss corresponding questions on porting.   Email: weidong.sun@freescale.com

Sometime need standalone compile device tree. Only Linux headers and device tree directory are needed.         

Hello there. Here is a good way to use U-boot in an efficient way with custom scripts. The bootscript is an script that is automatically executed when the boot loader starts, and before the OS auto boot process. The bootscript allows the user to execute a set of predefined U-Boot commands automatically before proceeding with normal OS boot. This is especially useful for production environments and targets which don’t have an available serial port for showing the U-Boot monitor. This information can be find in U-Boot Reference Manual.   I will take the example load a binary file in CORTEX M4 of IMX8MM-EVK. In my case, I have the binary file in MMC 2:1 called gpio.bin and I will skip those steps because that is not the goal.   First, you need the u-boot-tools installed in your Linux machine: sudo apt install u-boot-tools   That package provide to us the tool mkimage to convert a text file (.src, .txt) file to a bootscript file for U-Boot.   Now, create your custom script, in this case a simple script for load binary file in Cortex M4: nano mycustomscript.scr  and write your U-Boot commands: fatload mmc 2:1 0x80000000 gpio.bin cp.b 0x80000000 0x7e0000 0x10000 bootaux 0x7e0000   Now we can convert the text file to bootscript with mkimage. Syntax: mkimage -T script -n "Bootscript" -C none -d <input_file> <output_file> mkimage -T script -n "Bootscript" -C none -d mycustomscript.scr LCM4-bootscript   This will create a file called LCM4-bootscript (Or as your called it).   A way to load this bootscript file to U-Boot is using the UUU tool, in U-Boot set the device in fastboot with command: u-boot=> fastboot 0 Then in linux with the board connected through USB to PC run the command: sudo uuu -b fat_write LCM4-bootscript mmc 2:1 LCM4-bootscript   Now we have our bootscript in U-Boot in MMC 2:1.   Finally, we can run the bootscript in U-Boot: u-boot=> load mmc 2:1 ${loadaddr} LCM4-bootscript 158 bytes read in 2 ms (77.1 KiB/s) u-boot=> source ${loadaddr} ## Executing script at 40400000 6656 bytes read in 5 ms (1.3 MiB/s) ## No elf image at address 0x007e0000 ## Starting auxiliary core stack = 0x20020000, pc = 0x1FFE02CD...   And the Cortex M4 booted successfully:    I hope this can helps to you.   Best regards.   Salas.  

Symptoms   Trying to initialize a repo, for example:  $repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-mickledore -m imx-6.1.36-2.1.0.xml we have the below log: File "/home/username/bin/repo", line 51 def print(self, *args, **kwargs): ^ SyntaxError: invalid syntax   Workaround (1)   The first workaround consist in change the python alternatives (caused when you have installed two or more python versions). NOTE: in my case, the python version that i want to change as first priority is python3.8 $sudo update-alternatives --install /usr/bin/python python /usr/bin/python3.8 1   Then we run: $sudo update-alternatives --config python    To verify if your python priority was changed successfully try: $python --version   You should see the version configured as priority number 1.     Workaround (2)   The workaround is very simple, only we need modify the repo file $ nano ~/bin/repo   and we will change the python interpreter in the first line (from python to python3): ORIGINAL FILE   EDITED FILE   After to do this change, repo will works fine again.     I hope this can helps to you!   Best regards.

In some cases, such as mass production or preparing a demo. We need u-boot environment stored in demo sdcard mirror image.  Here is a way: HW:  i.MX8MP evk SW:  LF_v5.15.52-2.1.0_images_IMX8MPEVK.zip The idea is to use fw_setenv to set the sdcard mirror as the operation on a real emmc/sdcard. Add test=ABCD in u-boot-initial-env for test purpose. And use fw_printenv to check and use hexdump to double confirm it. The uboot env is already written into sdcard mirror(imx-image-multimedia-imx8mpevk.wic). All those operations are on the host x86/x64 PC. ./fw_setenv -c fw_env.config -f u-boot-initial-env Environment WRONG, copy 0 Cannot read environment, using default ./fw_printenv -c fw_env.config Environment OK, copy 0 jh_root_dtb=imx8mp-evk-root.dtb loadbootscript=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${bsp_script}; mmc_boot=if mmc dev ${devnum}; then devtype=mmc; run scan_dev_for_boot_part; fi arch=arm baudrate=115200 ...... ...... ...... splashimage=0x50000000 test=ABCD usb_boot=usb start; if usb dev ${devnum}; then devtype=usb; run scan_dev_for_boot_part; fi vendor=freescale hexdump -s 0x400000 -n 2000 -C imx-image-multimedia-imx8mpevk.wic 00400000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| hexdump -s 0x400000 -n 10000 -C imx-image-multimedia-imx8mpevk.wic 00400000 5f a4 9b 97 20 6a 68 5f 72 6f 6f 74 5f 64 74 62 |_... jh_root_dtb| 00400010 3d 69 6d 78 38 6d 70 2d 65 76 6b 2d 72 6f 6f 74 |=imx8mp-evk-root| 00400020 2e 64 74 62 00 20 6c 6f 61 64 62 6f 6f 74 73 63 |.dtb. loadbootsc| 00400030 72 69 70 74 3d 66 61 74 6c 6f 61 64 20 6d 6d 63 |ript=fatload mmc| 00400040 20 24 7b 6d 6d 63 64 65 76 7d 3a 24 7b 6d 6d 63 | ${mmcdev}:${mmc| 00400050 70 61 72 74 7d 20 24 7b 6c 6f 61 64 61 64 64 72 |part} ${loadaddr| 00400060 7d 20 24 7b 62 73 70 5f 73 63 72 69 70 74 7d 3b |} ${bsp_script};| 00400070 00 20 6d 6d 63 5f 62 6f 6f 74 3d 69 66 20 6d 6d |. mmc_boot=if mm| ...... ...... ...... 00401390 76 3d 31 00 73 6f 63 3d 69 6d 78 38 6d 00 73 70 |v=1.soc=imx8m.sp| 004013a0 6c 61 73 68 69 6d 61 67 65 3d 30 78 35 30 30 30 |lashimage=0x5000| 004013b0 30 30 30 30 00 74 65 73 74 3d 41 42 43 44 00 75 |0000.test=ABCD.u| 004013c0 73 62 5f 62 6f 6f 74 3d 75 73 62 20 73 74 61 72 |sb_boot=usb star| 004013d0 74 3b 20 69 66 20 75 73 62 20 64 65 76 20 24 7b |t; if usb dev ${| 004013e0 64 65 76 6e 75 6d 7d 3b 20 74 68 65 6e 20 64 65 |devnum}; then de| flash the sdcard mirror into i.MX8MP evk board emmc to check uuu -b emmc_all imx-boot-imx8mp-lpddr4-evk-sd.bin-flash_evk imx-image-multimedia-imx8mpevk.wic  The first time boot, the enviroment is already there.  How to achieve that: a. fw_setenv/fw_printenv: https://github.com/sbabic/libubootenv.git Note: Please do not use uboot fw_setenv/fw_printenv Compile it on the host x86/x64 PC. It is used on host. b. u-boot-initial-env Under uboot, make u-boot-initial-env Note: Yocto deploys u-boot-initial-env by default c. fw_env.config  imx-image-multimedia-imx8mpevk.wic 0x400000 0x4000 0x400000 0x4000 are from uboot-imx\configs\imx8mp_evk_defconfig CONFIG_ENV_SIZE=0x4000 CONFIG_ENV_OFFSET=0x400000 Now, you can run  ./fw_setenv -c fw_env.config -f u-boot-initial-env

Hello everyone, We have recently migrated our Source code from CAF (Codeaurora) to Github, so i.MX NXP old recipes/manifest that point to Codeaurora eventually will be modified so it points correctly to Github to avoid any issues while fetching using Yocto. Also, all repo init commands for old releases should be changed from: $ repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b <branch name> [ -m <release manifest>] To: $ repo init -u https://github.com/nxp-imx/imx-manifest -b <branch name> [ -m <release manifest>] This will also apply to all source code that was stored in Codeaurora, the new repository for all i.MX NXP source code is: https://github.com/nxp-imx For any issues regarding this, please create a community thread and/or a support ticket. Regards, Aldo.

We will build a remote debug environmet of Qt Creator in this user guide.   Contents 1 Change local.conf file in Yocto 2 2 Build and deploy Yocto SDK 2 2.1 Build full image SDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.2 Deploy SDK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3 Configure QT Kit 2 3.1 Setup device . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3.2 Configure QT version . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.3 Configure gcc and g++ manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.4 Configure gdb manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.5 Configure Kit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.6 Very important thing!! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4 Test result

  Question: How can we generate an ARM DS5 DStream format DDR initialization script using the DRAM Register Programming Aid?  Answer: Some RPAs include a  "DStream .ds file" tab for the ARM DS5 debugger specific commands. The i.MX6UL/ULL/ULZ DRAM Register Programming Aids for example already has this supported. However, the user can easily create  the .ds format from the existing .inc format. The basic steps to convert .inc files to .ds format are as follows: 1)  Replace the one instance of setmem /16 with mem set 2)  In that same line, replace 0x020bc000 = with 0x020bc000 16 3)  Use a Replace All command to change setmem /32 with mem set 4)  Use a Replace All command to change = with 32 5)  Use a Replace All command to change // with # 6)  Save as a .ds file.   Question: When using a 528MHz DRAM Controller interface with a DDR memory of a faster speed bin, which speed bin timing options should one use? Answer: For example, let’s assume our MX6DQ design is using a DDR3 memory from a DDR3-1600 speed bin.  However, the maximum speed of the MMDC interface for the MX6DQ using DDR3 is 528MHz.  Should we use the 1600 speed bin (800MHz clock speed) or the 1066 speed bin (533MHz clock speed)?  In short, the user should use the timings rated for the maximum speed (frequency) with which you are running, in this case DDR3-1066 (533MHz).  In some cases, like when using the MX6DL, the maximum DDR frequency is 400MHz.  In this case, you would want to try and use 800 timings found in the AC timing parameters table.  However, most DDR3 devices have speed bin tables that may go only as low as 1066, in which case you would use the closest speed bin to your operational frequency (i.e. the 1066 speed bin table).     Question: Some timing parameters may specify a min and max number, which should I use? Answer: In most cases, you will want to choose the minimum timings.  Some DRAM controllers may have a tRAS_MAX timing parameter, in which case you would obviously use the maximum tRAS parameter given in the DRAM data sheet. Also, for timing parameters tAONPD and tAOFPD, we also want to use the maximum values given in the DDR3 data sheet. These represent the maximum amount of time the DDR3 device takes to turn on or off the RTT (termination), therefore, we should wait at least this amount of time before issuing any commands or accesses.   Question: Some timing parameters state things like “Greater of 3CK or 7.5ns”; which should I use? Answer: This depends on your clock speed.  Say you are running at 533MHz.  At 533MHz, 7.5ns equates to 4CKs.  In this case, 7.5ns at 533MHz is GREATER than 3CK, so we would use the 7.5ns number, or 4CKs. At 400MHz, 7.5ns equates to 3CKs.  In this case, we’d simply use 3CKs.   Question: I have a design that will throttle the DDR frequency (dynamic frequency scaling).  At full speed, I plan to run at 533MHz, and then I plan to throttle down to say 400MHz whenever possible.  Do I need to re-calculate my 400 MHz timing parameters that were initially set for 533MHz? Answer: It is not necessary to re-calculate timing parameters for 400MHz, and you can re-use the ones for 533MHz.  The timings at 533 MHz are much tighter than 400 MHz, and the key here is to NOT violate timings.  Also, it may be a bit of a hassle maintaining two sets of timing parameters, especially if later in the design, you swap DDR vendors that might require you to re-calculate some timing parameters.  It’s easier to do it once and to come up with a combined worse-case timing parameters for 533MHz, which you know will work at 400MHz.  But, if you don’t mind maintaining two sets of timing parameters, and really want to optimize timings down to the last pico-second for 400MHz, then knock yourself out.   Question: Can I use these Register programming aids for both Fly by and T- Topology ? Answer Yes The DDR register programming aid is agnostic to the DDR layout. The same spreadsheet works for both topologies. We recommend running write leveling calibration for both topologies and the values returned by the Write Leveling routine from the Freescale DDR stress test should be incorporated back to the customer specific initialization script. The DDR stress test also has a feature whereby it evaluates the write leveling values returned from calibration and increments WALAT to 1 if the values exceed a defined limit. The DDR stress test informs the user when the Write Additional latency (WALAT) exceeds the limit and should be increased by 1, and reminds the user to add it back in the customer specific initialization script if required.   WALAT - 0 00000000 WALAT: Write Additional latency. Recommend to clear these bits. Proper board design should ensure that the DDR3 devices are placed close enough to the MMDC to ensure the skew between CLK and DQS is less than 1 cycle.     Question: Can I use the DEFAULT Register programming aid values for MDOR when using an Internal OSC instead of the recommended 32.768 KHZ XTAL ? Answer No, NXP recommends reprogramming these values based on the worse case frequency (Max clock) of the internal OSC of the device to guarantee JEDEC timings are met. Please refer to Internal Oscillator Accuracy considerations for the i.MX 6 Series for more details