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.

Hello! In this post, we’ll cross-compile a kernel module for Linux 6.12.    This can be done either using a standalone kernel or a Yocto-built kernel.    Requirements:  A compiled Linux kernel 6.12.  A board running the same kernel version (Linux 6.12 in this case).  A cross-compiler toolchain.    This process applies to any i.MX processor, including i.MX8, i.MX8M, i.MX8MM, i.MX8MN, i.MX8MP, i.MX93, i.MX91, i.MX95, as well as the i.MX6 and i.MX7 families.    Step 1: Compile the Linux Kernel and get the Toolchain    First, you need to compile the Linux kernel (6.12 in this case).    You can do this in a standalone environment or using Yocto.     If you are using a Standalone environment, please refer to the Chapter 4.5.12 How to build U-Boot and Kernel in standalone environment of i.MX Linux User's Guide.  Also, in that document section, you will see how to obtain the cross-compiler toolchain.    NOTE: To get the toolchain you need use Yocto at least once (for more information please refer to i.MX Yocto Project User's Guide😞  $ DISTRO=fsl-imx-xwayland MACHINE=Target-Machine bitbake core-image-minimal -c populate_sdk   At the end of the building, you can install your toolchain populated under:    yocto-bsp/build/tmp/deploy/sdk     There you will find a file called:    fsl-imx-wayland-glibc-x86_64-imx-image-core-armv8a-your-machine-name-toolchain-6.12-walnascar.sh    Execute with:  $ sudo ./fsl-imx-wayland-glibc-x86_64-imx-image-core-armv8a-your-machine-name-toolchain-6.12-walnascar.sh   If you use the default installation, you will have your toolchain under /opt in your host machine.      (If you will use the compiled kernel from Yocto, you can avoid below step)  Download Standalone Kernel source by cloning with:  $ git clone https://github.com/nxp-imx/linux-imx -b lf-6.12.y $ cd linux-imx   To build the kernel in the standalone environment for i.MX 6 and i.MX 7, execute the following commands:    $ make imx_v7_defconfig $ Make   To build the kernel in the standalone environment for i.MX 8 and i.MX 9, execute the following commands:  $ make imx_v8_defconfig $ make   The full kernel compilation is required to generate headers and symbol files required for external module compilation, even if you don't plan to boot this kernel directly.      Step 2: Write a simple Kernel Module to test    Now that your kernel is compiled, you can write a basic kernel module for testing.    Create a new directory. It will have our hello.c and Makefile.    We will create the file hello.c:  #include <linux/init.h> #include <linux/module.h> #include <linux/kernel.h> MODULE_LICENSE("GPL"); MODULE_AUTHOR("Salas"); MODULE_DESCRIPTION("A simple kernel module example for cross-compilation."); MODULE_VERSION("0.1"); static int __init hello_init(void) { printk(KERN_INFO "Hello from the kernel module!\n"); return 0; } static void __exit hello_exit(void) { printk(KERN_INFO "Goodbye from the kernel module!\n"); } module_init(hello_init); module_exit(hello_exit);   Then, create a basic Makefile to compile the modules:    # Module name obj-m += hello.o # Build flags ldflags-y += --strip-debug # Kernel source directory (provided by Yocto) KERNEL_SRC ?= /path/to/your/compiled/kernel # Build target all: $(MAKE) -C $(KERNEL_SRC) M=$(PWD) modules # Clean target clean: $(MAKE) -C $(KERNEL_SRC) M=$(PWD) clean # Install target modules_install: $(MAKE) -C $(KERNEL_SRC) M=$(PWD) modules_install   KERNEL_SRC should be your compiled kernel from your Yocto build:   yocto-bsp/build/tmp/work/your-machine-poky-linux/linux-imx/6.12.20+git/build   Or the Standalone : path/to/linux-imx/     Step 3: Set the toolchain and compile the kernel module    Finally, we can compile the kernel module.    First, set the toolchain (in my case):  $ source /opt/fsl-imx-wayland/6.12-walnascar/environment-setup-armv8a-poky-linux   Then, compile using the makefile:  $ make   f everything goes well, at final you will have the generated files:    hello.ko hello.mod hello.mod.c hello.mod.o hello.o Makefile modules.order Module.symvers   The one we need is the hello.ko (Kernel Object).    We can check if the file was created correctly using:    $ readelf -h hello.ko ELF Header: Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: REL (Relocatable file) Machine: AArch64 Version: 0x1 Entry point address: 0x0 Start of program headers: 0 (bytes into file) Start of section headers: 33992 (bytes into file) Flags: 0x0 Size of this header: 64 (bytes) Size of program headers: 0 (bytes) Number of program headers: 0 Size of section headers: 64 (bytes) Number of section headers: 41 Section header string table index: 40   We can see the Machine is AArch64 and the Type is a Relocatable file.      Step 4: Running the Kernel Object/Module in the board    Transfer the generated hello.ko file from your host machine to your board.    Then, In your board you can run with:    root@imx93evk:~# ls hello.ko root@imx93evk:~# insmod hello.ko root@imx93evk:~# dmesg | tail [ 5140.547447] Hello world from kernel! root@imx93evk:~# rmmod hello.ko root@imx93evk:~# dmesg | tail [ 5140.547447] Hello world from kernel! [ 5153.415215] Goodbye world from kernel!   I hope this can helps to you.    Best regards,  Salas. 

Quickly develop and deploy IoT applications with Clea on your NXP device. This guide walks you through setting up Clea, managing devices remotely, and leveraging AI-powered telemetry for industrial applications.

Check new updated version for with Morty here Step 1 : Get iMX Yocto AVS setup environment Review the steps under Chapter 3 of the i.MX_Yocto_Project_User'sGuide.pdf on the L4.X LINUX_DOCS to prepare your host machine. Including at least the following essential Yocto packages $ sudo apt-get install gawk wget git-core diffstat unzip texinfo \   gcc-multilib build-essential chrpath socat libsdl1.2-dev u-boot-tools Install the i.MX NXP AVS repo Create/Move to a directory where you want to install the AVS yocto build enviroment. Let's call this as <yocto_dir> $ cd <yocto_dir> $ repo init -u https://source.codeaurora.org/external/imxsupport/meta-avs-demos -b master -m imx7d-pico-avs-sdk_4.1.15-1.0.0.xml Download the AVS BSP build environment: $ repo sync Step 2: Setup yocto for Alexa_SDK image with AVS-SETUP-DEMO script: Run the avs-setup-demo script as follows to setup your environment for the imx7d-pico board: $ MACHINE=imx7d-pico DISTRO=fsl-imx-x11 source avs-setup-demo.sh -b <build_sdk> Where <build_sdk> is the name you will give to your build folder. After acepting the EULA the script will prompt if you want to enable: Sound Card selection The following Sound Cards are supported on the build: SGTL (In-board Audio Codec for PicoPi) 2-Mic Conexant The script will prompt if you are going to use the Conexant Card. If not then SGTL will be assumed as your selection Are you going to use Conexant Sound Card [Y/N]? Install Alexa SDK Next option is to select if you want to pre-install the AVS SDK software on the image. Do you want to build/include the AVS_SDK package on this image(Y/N)? If you select YES, then your image will contain the AVS SDK ready to use (after authentication). Note this AVS_SDK will not have WakeWord detection support, but it can be added on runtime. If your selection was NO, then you can always manually fetch and build the AVS_SDK on runtime. All the packages dependencies will be already there, so only fetching the AVS_SDK source code and building it is required. Finish avs-image configuration At the end you will see a text according with the configuration you select for your image build. Next is an example for a Preinstalled AVS_SDK with Conxant Sound Card support and WiFi/BT not enabled. ==========================================================   AVS configuration is now ready at conf/local.conf             - Sound Card = Conexant                                     - AVS_SDK pre-installed                                       You are ready to bitbake your AVS demo image now:               bitbake avs-image                                        ========================================================== Step 3: Build the AVS image Go to your <build_sdk> directory and start the build of the avs-image There are 2 options Regular Build: $ cd <yocto_dir>/<build_sdk> $ bitbake avs-image With QT5 support included: $ cd <yocto_dir>/<build_sdk> $ bitbake avs-image-qt5 The image with QT5 is useful if you want to add some GUI for example to render DisplayCards. Step 4 : Deploying the built images to SD/MMC card to boot on target board. After a build has succesfully completed, the created image resides at <build_sdk>/tmp/deploy/images/imx7d-pico/ In this directory, you will find the imx7d-pico-avs.sdcard image or imx7d-pico-avs-qt5.sdcard, depending on the build you chose on Step3. To Flash the .sdcard image into the eMMC device of your PicoPi board follow the next steps: Download the bootbomb flasher Follow the instruction on Section 4. Board Reflashing of the Quick Start Guide for AVS kit to setup your board on flashing mode. Copy the built SDCARD file $ sudo dd if=imx7d-pico-avs.sdcard of=/dev/sd bs=1M && sync $ sync Properly eject the pico-imx7d board: $ sudo eject /dev/sd NXP Documentation Refer to the Quick Start Quide for AVS SDK to fully setup your PicoPi board with Synaptics 2Mic and PicoPi i.mx7D For a more comprehensive understanding of Yocto, its features and setup; more image build and deployment options and customization, please take a look at the i.MX_Yocto_Project_User's_Guide.pdf document from the Linux documents bundle mentioned at the beginning of this document. For a more detailed description of the Linux BSP, u-boot use and configuration, please take a look at the i.MX_Linux_User's_Guide.pdf document from the Linux documents bundle mentioned at the beginning of this document.

The iMX8QM LVDS has followed work mode, (There are two LVDS modules in IMX8QM): Single mode (LVDS panel connects to one channel) panel 1 and panel 2 can be different panels: Dual channel split mode (The panel needs two LVDS channels, CH0 for 1,3,5,7,... pixels and CH1 for 2,4,6,8,... pixels): Mirror dual mode (The two panels on same LDB PHY should be same panels on pixel clock and resolution, panel 1 and panel 2 are same; panel 3 and panel 4 are same): The reference patch is based on L5.4.3_GA1.0.0 BSP. LVDS single mode and dual channel split mode are supported in default Linux BSP. Patch 0002 can be used to test this dual mode on MEK board, some rework is needed on MEK board:     R194, R195, R208, R209, R213, R214 should be mounted. And the I6263 board can't be connected to LVDS0_CH0 and LVDS0_CH1 at the same time. The I6263 board can't be connected to LVDS1_CH0 and LVDS1_CH1 at the same time too. Note: for iMX8QXP, there is no mirror dual mode support, because its two LVDS ports are from two different LDB modules, there are no CH1 for them: Note: for iMX8QXP dual channel split mode (The pixel order can be switched: LDB1_CH0 for 1,3,5,7,... pixels and LDB2_CH0 for 2,4,6,8,... pixels; or LDB2_CH0 for 1,3,5,7,... pixels and LDB1_CH0 for 2,4,6,8,... pixels), iMX8QM LVDS has no such feature.

On the build folder, type bitbake -g <image> && cat pn-depends.dot | grep -v -e '-native' | grep -v digraph | grep -v -e '-image' | awk '{print $1}' | sort | uniq where <image> is the image name (e.g. core-image-minimal). In case you want to know if a certain <package> is included on an image, just grep the output bitbake -g <image> && cat pn-depends.dot | grep -v -e '-native' | grep -v digraph | grep -v -e '-image' | awk '{print $1}' | sort | uniq | grep <package>

You can boot from SPI NOR Flash using the following procedure:      1 - Download ATK Release 1.7. The version ATK 1.7 can be downloaded here. 2 - Unzip file iMX_AdvancedToolKit_R170.zip into "C:\Program Files\freescale\AdvancedToolKit-STD\image\".      3 - Open the file "C:\Program Files\freescale\AdvancedToolKit-STD\config\ADSToolkit.cfg" and add the following lines: [MX25_TO11] MMC/SD::image\mx25_mmc.bin:0x(unknown) NAND::image\mx25_nand.bin:0x(unknown) SPI::image\mx25_spi.bin:0x(unknown) [MX31]   4 - Set the SPI Boot Config on MX25PDK:   SW22: no influence SW21[1-8]: 11110010 BT_MEM_CTL[0:1] = 11 (Expansion) BT_MEM_TYPE[0:1] = 11 (Serial ROM via SPI) BT_PAGE_SIZE[0:1] = no influence BT_BUS_WIDTH[0:1] = 10 (3-Address SPI (24-bit) Note: BT_BUS_WIDTH[0]=1, BT_BUS_WIDTH[1]=0 On Debug Board the red switches: (SW5-SW10) = 000011 (0=off) Boot Config Switches (SW21, SW22) on Personality Board have no influence.   5 - Connect USB or Serial cable between Host PC and PDK and execute ATK   6 - Select USB/UART serial boot on MX25PDK and power on the board   7 - Configure ATK as following: Device = i.MX25_TO1.1 device memory initial = DDR2 Communication channel: COMn (select the COM port on your PC) or Communication channel: USB If you choose COM (serial UART connection) you MUST disconnect USB cable from OTG connector on i.MX25 PDK.   8 - Configure ATK "Flash Tool" as following: Tick "Program" Tick "Read Back Check" Flash Model = SPI Address = 0x0 Image = mx25_3stack_redboot_TO1_1.bin (same file as for NAND boot). Same should be applicable to U-boot.   Note: SPI NOR Boot requires internal boot mode. On Debug Card all red switches must be off (SW5-SW10) = 000000 (0=off). Note: if booting from SPI NOR, Redboot needs approx 2 seconds before it shows messages on the console.

Platform: I.MX8MMEVK uboot version:  uboot-imx_lf_v2023.04 BSP: 6.1.x Add patch in uboot git clone https://github.com/nxp-imx/uboot-imx.git git checkout lf_v2023.04 git apply 0001-Enable-imx8mm-pcie-driver-v2023.04.patch   test log: u-boot=> pci enum pcie phy base: 0x32f00000, size 0x10000 pcie phy pll is locked after 0 us. Link up, Gen1 u-boot=> pci BusDevFun VendorId DeviceId Device Class Sub-Class _____________________________________________________________ 00.00.00 0x16c3 0xabcd Bridge device 0x04 01.00.00 0x1131 0x3003 Network controller 0x00 01.00.01 0x1131 0x3004 Network controller 0x00  

A new release of the manufacturing tool is was recently made available, "imx-3.10.53_1.1.0_ga-mfg-tools". It can be found in the software download sections for the iMX6 family. However, it can be used to program an iMX28 in a Win7 64-bit host by adding a few files. The steps to do so are listed below and can be checked against the script in ucl2.xml.   Download the attached "28.vbs" file and place it into where the manufacturing tool was installed, typically in  <install_dir>\mfgtools\   Replace <install_dir>\mfgtools\Profiles\Linux\OS Firmware\ucl2.xml with the attached ucl2.xml.    Copy the attached files "updater_ivt.sb" and "fdisk-u.input" into <install_dir>\mfgtools\Profiles\Linux\OS Firmware\firmware Copy your iMX28 image file into <install_dir>\mfgtools\Profiles\Linux\OS Firmware\files.  The file should be renamed to "linux.sb" to conform with the ucl2.xml script. Copy your "rootfs.tar.bz2" file into <install_dir>\mfgtools\Profiles\Linux\OS Firmware\files To launch the manufacturing tool, double click on "28.vbs". Issue: After MfgTool has finished and the progress bars have turned green, clock on the Stop button or the program will start another cycle.

About this document This document describe the setup detail for Robot Operating systems on  ubuntu 14.04 running on MX6QDL based boards. 1. Software & Hardware requirements Supported NXP HW boards: i.MX 6QuadPlus SABRE-SD Board and Platform i.MX 6Quad SABRE-SD Board and Platform i.MX 6DualLite SABRE-SD Board i.MX 6Quad SABRE-AI Board i.MX 6DualLite SABRE-AI Board i.MX 6SoloX SABRE-SD Board i.MX 6SoloX SABRE-AI Board i.MX 7D Sabre Board Software:  Gcc toolchain, Ubuntu 14.04v installed on your board. 2. Installation For install ROS on iMX boards you need to have Ubuntu 14.04 rootfs installed in your board, for installation steps please follow up: https://community.freescale.com/docs/DOC-330147 Run your rootfs target and Configure your Ubuntu repositories to allow "restricted," "universe," and "multiverse.  $sudo nano /etc/apt/sources.list Your file should then look like this: deb http://ports.ubuntu.com/ubuntu-ports/ trusty main universe multiverse restricted deb-src http://ports.ubuntu.com/ubuntu-ports/ trusty main universe multiverse restricted deb http://ports.ubuntu.com/ubuntu-ports/ trusty-updates main universe multiverse restricted Make your installation up to date: $ sudo apt-get update $ sudo apt-get upgrade Set your locale: $ sudo update-locale LANG=C LANGUAGE=C LC_ALL=C LC_MESSAGES=POSIX Add ROS ARM repos & Key $ sudo sh -c 'echo "deb http://packages.ros.org/ros/ubuntu $(lsb_release -sc) main" > /etc/apt/sources.list.d/ros-latest.list' $ sudo apt-key adv --keyserver hkp://pool.sks-keyservers.net --recv-key 0xB01FA116 $ sudo apt-get update There are many different libraries and tools in ROS - not all compile fully on ARM. In this case we are going to install the ROS Base, however any other packages can be installed individually ROS-Base: (Bare Bones) ROS package, build, and communication libraries. No GUI tools. $ sudo apt-get install python-rosdep python-wstool build-essential cmake xserver-xorg-dev-lts-utopic mesa-common-dev-lts-utopic \ libxatracker-dev-lts-utopic libopenvg1-mesa-dev-lts-utopic libgles2-mesa-dev-lts-utopic libgles1-mesa-dev-lts-utopic\ libgl1-mesa-dev-lts-utopic libgbm-dev-lts-utopic libegl1-mesa-dev-lts-utopic Alternatively, try installing just this to fix dependency issues, and then install ROS base (includes ROS package, build, and communication libraries. No GUI tools.😞 $ sudo apt-get install libgl1-mesa-dev-lts-utopic $ sudo apt-get install ros-indigo-ros-base Before you can use ROS, you will need to initialize rosdep. It enables you to easily install system dependencies for source you want to compile and is required to run some core components in ROS. $ sudo rosdep init $ rosdep update Install rosinstall: $ sudo apt-get install python-rosinstall Verifying OS name. If you installed the Linaro ALIP rootfs, make sure your OS name defined at /etc/lsb-release is as the following. Since ros does not recognize Linaro as an OS, this is necessary. $ lsb_release -a You should get: No LSB modules are available. Distributor ID: Ubuntu Description:    Ubuntu 14.04.4 LTS Release:        14.04 Codename:       trusty In any case you get a different output, the following is for Ubuntu 14.04, trusty. Modify the release number and name as per your target. DISTRIB_ID=Ubuntu DISTRIB_RELEASE=14.04 DISTRIB_CODENAME=trusty DISTRIB_DESCRIPTION="Ubuntu 14.04" 3. Testing The Installation Run ROS $ roscore You should get: ... logging to /root/.ros/log/1c07caa4-1dd3-11b2-b860-00049f0399fe/roslaunch- imx6q-2707.log Checking log directory for disk usage. This may take awhile. Press Ctrl-C to interrupt Done checking log file disk usage. Usage is <1GB. Started roslaunch server http://i.Mx6q:37547/ ros_comm version 1.11.16 SUMMARY ======== PARAMETERS * /rosdistro: indigo * /rosversion: 1.11.16 NODES auto-starting new master process[master]: started with pid [2718] ROS_MASTER_URI=http://imx6q:11311/ setting /run_id to 1c07caa4-1dd3-11b2-b860-00049f0399fe process[rosout-1]: started with pid [2731] started core service [/rosout] Open a new Terminal and Create the user catkin_ws Workspace. The catkin_ws workspace will contain the user packages. $ source /opt/ros/indigo/setup.bash $ mkdir -p ~/catkin_ws/src $ cd ~/catkin_ws/src $ catkin_init_workspace $ cd ~/catkin_ws/ $ catkin_make The  catkin_make command is a convenience tool for working with catkin_workspace. If you look in your current directory you should now have a 'build' and 'devel' folder. Inside the 'devel' folder you can see that there are now several setup.*sh files. Sourcing any of these files will overlay this workspace on top of your environment. To understand more about this see the general catkin documentation: http://wiki.ros.org/catkin Before continuing source your new setup.*sh file: $ source devel/setup.bash To make sure your workspace is properly overlayed by the setup script, make sure ROS_PACKAGE_PATH environment variable includes the directory you're in. $ echo $ROS_PACKAGE_PATH /home/youruser/catkin_ws/src:/opt/ros/indigo/share:/opt/ros/indigo/stacks Next you should go ahead and learn how to use the workspace. If you are following the ROS tutorials series instead of the catkin tutorials, please continue with Creating a ROS Package. For more testing on your installation, you can try the ROS Tutorials (http://wiki.ros.org/ROS/Tutorials)

Quick Steps Four quick steps to build and flash a UBIFS image on i.MX35 NAND (K9LBG08U0D-PCB0), for information on how to you another memory, please see next section. Enable MTD_UBI and UBIFS_FS on kernel Create UBI image from rootfs (used for NFS) - ON PC mkfs.ubifs -v -r rootfs -m 2048 -e 258048 -c 966 -o ubifs.img ubinize -o ubi.img -m 2048 -p 256KiB -s 2048 ubinize.cfg Format NAND using UBI image - ON TARGET ubiformat -f ubi.img /dev/mtd8 Load UBI file system load -r -b 0x100000 zImage fis create -f 0x300000 kernel fis load kernel exec -c "noinitrd console=ttymxc0 115200 ubi.mtd=8 root=ubi0:rootfs rw rootfstype=ubifs ip=none" How To First of all, install mtd-utils on both target and host: Target: ./ltib -c Package list [*] mtd-utils Host sudo aptget install mtd-utils 1. Enable MTD_UBI and UBIFS_FS on kernel MTD_UBI -> Device Drivers     -> Memory Technology Device (MTD) support (MTD [=y])           -> UBI - Unsorted block images                   <*> Enable UBI                    (4096) UBI wear-leveling threshold (NEW)                    (1) Percentage of reserved eraseblocks for bad eraseblocks handling (NEW)                 < > MTD devices emulation driver (gluebi) (NEW)                    ** UBI debugging options **                    [ ] UBI debugging (NEW) UBIFS_FS -> File systems         ->Miscellaneous filesystems             <*> UBIFS file system support                 [ ] Extended attributes support (NEW)                 [ ] Advanced compression options (NEW)                 [ ] Enable debugging (NEW) 2. Create UBI image On TARGET Collect some information needed in order to create the UBI image according to your NAND device root@freescale \~$ cat /proc/mtd dev:   size   erasesize name mtd0: 00080000 00020000 "Bootloader" mtd1: 00400000 00020000 "nor.Kernel" mtd2: 01e00000 00020000 "nor.userfs" mtd3: 01c00000 00020000 "nor.rootfs" mtd4: 00003000 00020000 "FIS directory" mtd5: 02001000 00020000 "Redboot config" mtd6: 00300000 00040000 "nand.bootloader" mtd7: 00500000 00040000 "nand.kernel" mtd8: 10000000 00040000 "nand.rootfs" mtd9: 00800000 00040000 "nand.configure" mtd10: 6f000000 00040000 "nand.userfs" I will use mtd8, because I want the NAND rootfs MTD partition. More on [1] root@freescale ~$ ubiattach /dev/ubi_ctrl -m 8 UBI: attaching mtd8 to ubi0 UBI: physical eraseblock size:   262144 bytes (256 KiB) UBI: logical eraseblock size:    258048 bytes UBI: smallest flash I/O unit:    2048 UBI: VID header offset:          2048 (aligned 2048) UBI: data offset:                4096 UBI: empty MTD device detected UBI: create volume table (copy #1) UBI: create volume table (copy #2) UBI: attached mtd8 to ubi0 UBI: MTD device name:            "nand.rootfs" UBI: MTD device size:            256 MiB UBI: number of good PEBs:        979 UBI: number of bad PEBs:         45 UBI: max. allowed volumes:       128 UBI: wear-leveling threshold:    4096 UBI: number of internal volumes: 1 UBI: number of user volumes:     0 UBI: available PEBs:             966 UBI: total number of reserved PEBs: 13 UBI: number of PEBs reserved for bad PEB handling: 9 UBI: max/mean erase counter: 0/0 UBI: image sequence number: 0 UBI: background thread "ubi_bgt0d" started, PID 2098 UBI device number You will need: -p = physical eraseblock size = 256KiB -e = logical eraseblock size = 258048 -m = smallest flash I/O unit = 2048 -s = VID header offset = 2048 -c = available PEB = 966 Values only for iMX35 PDK NAND - K9LBG08U0D-PCB0 3. ON HOST - Now, create the images (two steps) You need to create ubinize.cfg file! ubinize.cfg [ubifs] mode=ubi image=ubifs.img vol_id=0 vol_size=237MiB vol_type=dynamic vol_name=rootfs vol_flags=autoresize $ mkfs.ubifs -v -r rootfs -m 2048 -e 258048 -c 966 -o ubifs.img mkfs.ubifs      root:                rootfs/      min_io_size:    2048      leb_size:         258048      max_leb_cnt:   966      output:            ubifs.img      jrn_size:          8388608      reserved:         0      compr:            lzo      keyhash:         r5      fanout:            8      orph_lebs:       1      super lebs:      1      master lebs:    2      log_lebs:         4      lpt_lebs:          2      orph_lebs:       1      main_lebs:       132      gc lebs:           1      index lebs:       2      leb_cnt:           142      UUID:              CC2057F9-B20F-46D1-A399-1FCA95DCAFF7 Success\! $ ubinize -o ubi.img -m 2048 -p 256KiB -s 2048 ubinize.cfg $ ls -lh u* -rw-r--r-- 1 daiane daiane 35M 2010-11-26 15:21 ubifs.img -rw-r--r-- 1 daiane daiane 36M 2010-11-26 15:22 ubi.img -rw-r--r-- 1 daiane daiane 113 2010-11-26 15:22 ubinize.cfg $ sudo cp ubi.img rootfs/home/ 4. Format NAND using UBI image - ON TARGET Turn on target (or reset it) and format MTD partition $ cd /home $ ubiformat -f ubi.img /dev/mtd8 5. Load UBI file system Reset and change redboot script: .. fis load kernel .. exec -c "noinitrd console=ttymxc0 115200 ubi.mtd=8 root=ubi0:rootfs rw rootfstype=ubifs ip=none"

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

This article describes how to use the Preempt-RT Linux kernel in the i.MX Linux BSP 6.6.23_2.0.0. This is particularly useful for platforms such as i.MX 95, for which there is not yet a Real-Time Edge Software release.    How to do it    1. Follow the steps in the i.MX Yocto Project User's Guide and build your preferred image, for example core-image-minimal. Will further assume that the BSP is in the ~/imx-yocto-bsp directory and the build directory is ~/imx-yocto-bsp/build. 2. Unpack the attached archive in ~/imx-yocto-bsp/sources. This should create the ~/imx-yocto-bsp/sources/meta-otherkernels directory. This archive will work out of the box for i.MX 95 and i.MX 93, and may require some modifications for other platforms, as described below. 3. Add the meta-otherkernels to your build using the following command: bitbake-layers add-layer ~/imx-yocto-bsp/sources/meta-otherkernels 4. Add the OVERRIDES .= ":preempt-rt" to ~/imx-yocto-bsp/build/conf/local.conf file using the following command: echo 'OVERRIDES .= ":preempt-rt"' >> ~/imx-yocto-bsp/build/conf/local.conf This enables the Preempt-RT kernel for your build. You can always go back to your regular kernel by removing this line from ~/imx-yocto-bsp/build/conf/local.conf. 5. Build again your image. After booting this image, you can check the kernel version using: uname -a      How it works    The meta-otherkernels layer contains a .bbappend  for the linux-imx kernel recipe which replaces the sources URL with the Real-Time Edge kernel when the "preempt-rt" override is active. In addition, due to the fact that the current real-time kernel does not support all the board configurations, the layer config file (meta-otherkernels/conf/layer.conf) removes from the build the device tree files that are not supported (when "preempt-rt" override is active).   If you use this layer for other SoCs (other than i.MX 93/i.MX 95), you may need to edit the meta-otherkernels/conf/layer.conf and add the unsupported device trees. If an  unsupported device tree is left, Yocto will give an error during build.        *** DISCLAIMER *** Any support, information, and technology (“Materials”) provided by NXP are provided AS IS, without any warranty express or implied, and NXP disclaims all direct and indirect liability and damages in connection with the Material to the maximum extent permitted by the applicable law. NXP accepts no liability for any assistance with applications or product design. Materials may only be used in connection with NXP products. Any feedback provided to NXP regarding the Materials may be used by NXP without restriction.

Description       this doc is explain how to develop a audio card driver base on i.MX6 platform. which explain the ASOC architecture struction basic knowledage and then give some sample for the audio driver development like: 1:NXP SGTL5000: NXP i.MX BSP sabrelite board default support it. 2: Wolfson WM8524.    A: 3.0.35 BSP support: i.MX6 setbox BSP support it:(which in elder fsl community link and out of data)    B: 3.14.28 BSP support pls check attachment: 3: Wolfson WM8960.     which include how to add the android middle-layer and driver, pls check attachment. 4: TI TLV320AIC3120      which include how to add the android middle-layer and driver, pls check attachment. 5: TI TLV320AIC3X   Products Product Category NXP Part Number URL MPU i.MX6 Family https://www.nxp.com/products/processors-and-microcontrollers/arm-processors/i-mx-applications-processors/i-mx-6-processors:IMX6X_SERIES   Tools NXP Development Board URL i.MX6 SabreSDP https://www.nxp.com/design/development-boards:EVDEBRDSSYS#/collection=softwaretools&start=0&max=25&query=typeTax%3E%3Et633::archived%3E%3E0::Sub_Asset_Type%3E%3ETSP::deviceTax%3E%3Ec731_c380_c127_c126&sorting=Buy%2FSpecifications.desc&language=en&siblings=false which have a doc MX6X_ASOC_V5-20191115.pdf and related driver sample codes.

The System Controller Unit (SCU) is in charge of controlling several features related to power management of the whole system. The user gets access to the following features through the System Controller Firmware: Powering up/down the system,resources and partitions Configuring resource clocks Reset controls Configuring wake-up sources This document will cover the more commonly used features, for details on the full capabilities of the API please refer to the API document for your device. Resource Power Control The SCU is in charge of managing power control to the resources (peripherals) in the SoC. Attempting to access a resource on the OFF state will result in a bus error or a hang All resources are organized within several subsystems, subsystems group together resources with common functionality. Subsystems are independent of each other and have their own PLLs and power domains, this allows modular control of clocks and power to the resources. The System Controller Unit has a dedicated I2C channel to interact with the PMIC, this allows dynamic control of some power sources for resources like the GPUs and Cortex-A cores. The SCU can enable/disable the LDO that supplies power to the GPU for instance and also turn on/off the internal power domains. The mapping of PMIC supplies and resources happens on the board.c (included in the SCFW Porting kit) and it is part of the porting process of the SCFW to new boards. The function board_get_pmic_info is where the mapping of resources to supplies happen, see: /*--------------------------------------------------------------------------*/ /* Get the pmic ids and switchers connected to SS. */ /*--------------------------------------------------------------------------*/ static void board_get_pmic_info(sc_sub_t ss,pmic_id_t *pmic_id, uint32_t *pmic_reg, uint8_t *num_regs) { /* Map SS/PD to PMIC switch */ switch (ss) { case SC_SUBSYS_A53 : pmic_init(); {/* PF8100_dual Card */ pmic_id[0] = PMIC_0_ADDR; pmic_reg[0] = PF8100_SW5; *num_regs = 1U; } break; case SC_SUBSYS_A72 : pmic_init(); {/* PF8100_dual Card */ pmic_id[0] = PMIC_0_ADDR; pmic_reg[0] = PF8100_SW3; pmic_id[1] = PMIC_0_ADDR; pmic_reg[1] = PF8100_SW4; *num_regs = 2U; } break; case SC_SUBSYS_GPU_0 : pmic_init(); {/* PF8100_dual Card */ pmic_id[0] = PMIC_1_ADDR; pmic_reg[0] = PF8100_SW1; pmic_id[1] = PMIC_1_ADDR; pmic_reg[1] = PF8100_SW2; *num_regs = 2U; } break; case SC_SUBSYS_GPU_1 : pmic_init(); {/* PF8100_dual Card */ pmic_id[0] = PMIC_1_ADDR; pmic_reg[0] = PF8100_SW3; pmic_id[1] = PMIC_1_ADDR; pmic_reg[1] = PF8100_SW4; *num_regs = 2U; } break; default : ; /* Intentional empty default */ break; } }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Only some subsystems have their own dedicated external power supplies, in the example above A cores and GPUs are the only ones with a dedicated external power supplies. Most of the other subsystems are powered from the main power supply and power gating happens internally, each subsystem contains different power domains that can be turned on/off to manage power consumption. The SCFW API used to power on/off resources is the following: sc_err_t sc_pm_set_resource_power_mode (sc_ipc_t ipc, sc_rsrc_t resource, sc_pm_power_mode_t mode)‍‍‍‍‍ Where: ipc - is the interprocessor communication channel used to communicate with the SCU (obtained by calling sc_ipc_open). resource - is the resource that will have the power mode change mode - is the power mode to change to The available power mode options are the following: Power mode Voltage Clocks SC_PM_PW_MODE_OFF OFF All clocks off SC_PM_PW_MODE_STBY ON All clocks off SC_PM_PW_MODE_LP ON PLLs off resource running from XTAL SC_PM_PW_MODE_ON ON PLLs on In order to be able to access a resource it must be at least on SC_PM_PW_MODE_LP mode, since that mode has the resource voltage on and the clock is supplied by the 24MHz crystal. For more details please refer to the SCFW API document. Clocks Configuration As in the power management case, clocks are also organized in a distributed manner within the device. Each subsystem has it's own PLLs and all of them are clocked by the 24MHz crystal. The number of PLLs in each subsystem varies between all subsystems. To see how many PLLs are within a subsystem please refer to the datasheet of the device you are interested on. For instance on the datasheet of the i.MX8QXP on table 16 in Chapter 4.3.1: It can be seen that the GPU subsystem contains two PLLs, the ADMA subsystem contains 4 PLLs, Display Controller 3, etc... The SCFW API used to configure a clock is the following: sc_err_t sc_pm_set_clock_rate ( sc_ipc_t ipc, sc_rsrc_t resource, sc_pm_clk_t clk, sc_pm_clock_rate_t ∗ rate )‍‍‍‍‍ Where: ipc - is the interprocessor communication channel used to communicate with the SCU (obtained by calling sc_ipc_open). resource - is the resource that will have the clock rate change clk - is the clock to set the rate to (each resource can have different clocks associated with it for instance the GPU resource has a clock associated for its shader and another for the GPU, this parameter is used to identify the clock) rate - this contains the desired clock rate, the SCFW will try to match the provided rate if not possible it will then set the closest possible value and return the value that was actually configured. To identify the clk that needs to be passed, please refer to the SCFW API chapter called "Clock List" That chapter contains a table with all the different clocks that are configurable by the SCFW, in the case of the GPUs for instance to select the rate for the Shader or GPU, either the SC_PM_CLK_MISC or SC_PM_CLK_PER options would have to be selected. Set=Y indicates the clock/PLL is not shared and the rate can be set via sc_pm_set_clock_rate(). Enable=Y indicates the clock is not auto gated and must be enabled via sc_pm_clock_enable(). As an example the following snippet configures the GPU_0 shader clock: sc_clock_rate_t shader_clk=700000000; // 700 MHz sc_pm_set_clock_rate(ipc, SC_R_GPU_0_PID0, SC_PM_CLK_MISC, &shader_clk);‍‍ System Controller Firmware 101 

In Chinese Twitter: Sino Weibo, one famous distributor mentioned “i.MX28 is the best choice in ARM9 core-based processor, no ‘one of’”. With high integration of analog module and digital module, i.MX28 is attracting more and more engineers in various applications. Despite its advantage, there are some mistakes one may commit or issues they may meet. The note records a number of issues/mistakes. Each case in the note comes from a real story. I hope the note will help you in your development work. And It is definitely welcomed for everyone to add your own content to the note.The more you share, the more you get.

Introduction. In some cases, such as development stages, testing, validate flash process from zero, etc. It is needed to erase the eMMC storage device, here is described the process and the required equipment: Required equipment. i.MX93 FRDM board (this is the selected board for this post, it works for others). Debug USB-C cable. Data USB-C cable. Micro SD (16GB recommended). Personal computer. How to erase the eMMC? This method will use another boot source (Micro SD) to erase the eMMC so, it is needed to flash the Micro SD with at least the bootloader (U-boot), you can use a prebuilt image for the EVK board, it can be downloaded from the following link. But, in the case of i.MX93 FRDM board, there is no pre-built image available and needs to be build: The FRDM-IMX93 BSP release is based on i.MX SW 2024 Q3 release with Yocto Project 5.0 (Scarthgap). To build FRDM-IMX93 image from source code, please first check i.MX Yocto Project User's Guide to get familiar with Yocto project and Yocto build. Then please follow below steps to build image for FRDM-IMX93. 1. Download i.MX SW 2024 Q3 BSP Release: $ repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-scarthgap -m imx-6.6.36-2.1.0.xml $ repo sync 2. Integrate FRDM-MX93 layer into Yocto code base: $ cd ${MY_YOCTO}/sources $ git clone https://github.com/nxp-imx-support/meta-imx-frdm.git 3. Yocto Project Setup: $ MACHINE=imx93frdm DISTRO=fsl-imx-xwayland source sources/meta-imx-frdm/tools/imx-frdm-setup.sh -b frdm-imx93 4. Build images: $ bitbake imx-image-full The flashing process can be consulted here. Once the board is flashed, we need to change the boot switches to boot from Micro SD and turn-on the board. To debug this process, we will use Tera Term terminal with the board connected from the Micro USB debug cable to the PC and select the next configuration: Please verify that you are selecting the corresponding COM for Cortex-A debug. After boot we need to press a key, and the board will enter to U-boot. So, then we need to select the partition of the eMMC with the next command: u-boot=> mmc dev <storage device> <partition> In the case of the eMMC, the storage device corresponds to the device "0" and if the device has an image flashed into the eMMC e.g. Linux, the device will have three partitions from 0 to 2. The next command will select the eMMC and the boot partition area: u-boot=> mmc dev 0 0 switch to partitions #0, OK mmc0(part 0) is current device Depending on the device, image, etc. This partition size can vary so, we need to know how many blocks it has. We can use the next command that will let us know the max address value that is assigned to this partition by getting an error on the address that is out of the range. u-boot=> mmc read ${loadaddr} 0x7fffffff 1 MMC read: dev # 0, block # 2147483647, count 1 ... MMC: block number 0x80000000 exceeds max(0x1d5a000) 0 blocks read: ERROR Now, with this information, we are able to erase the entire partition with the next command: u-boot=> mmc erase 0 0x1d5a000 MMC erase: dev # 0, block # 0, count 30777344 ... 30777344 blocks erased: OK As mentioned before, the device has multiple partitions so, this process needs to be done in each partition Boot area Partition. User Area 1 Partition. User Area 2 Partition. But the process is the same, let's change the partition to User Area 1: u-boot=> mmc dev 0 1 switch to partitions #1, OK mmc0(part 1) is current device  Confirm the size of the partition: u-boot=> mmc read ${loadaddr} 0x7fffffff 1 MMC read: dev # 0, block # 2147483647, count 1 ... MMC: block number 0x80000000 exceeds max(0x2000) 0 blocks read: ERROR And erase it: u-boot=> mmc erase 0 0x2000 MMC erase: dev # 0, block # 0, count 8192 ... 8192 blocks erased: OK And let's finish with User Area 2 Partition: u-boot=> mmc dev 0 2 switch to partitions #2, OK mmc0(part 2) is current device u-boot=> mmc read ${loadaddr} 0x7fffffff 1 MMC read: dev # 0, block # 2147483647, count 1 ... MMC: block number 0x80000000 exceeds max(0x2000) 0 blocks read: ERROR u-boot=> mmc erase 0 0x2000 MMC erase: dev # 0, block # 0, count 8192 ... 8192 blocks erased: OK With this done, the eMMC is completely erased and you can confirm it by turning off the board, change the boot switched to eMMC, remove the SD card and turn-on the board.  Since there is not a bootable image into the boot source, the board will jump to serial download mode and you can verify connecting the USB data cable to the board and run the next command in UUU: Conclusion. Erasing the eMMC of the board is optional step in your development stage but also helpful for testing or system recovery (e.g. test manufacture mode). By using a Micro SD you can access to the eMMC and do all the modifications in the partitions that you want without issues. With this you can go to a clean storage state into the boot device and test a new image from scratch or test recovery methods in your design.