i.MX Processors Knowledge Base

Discussions

Purpose Under some situations, need to modify the binary image. Under some situations, no development environment. Under some situations, even no Linux. Only have windows. Board bring up need simple settings, such as simple/tiny rootfs. Key Features Create small sdcard mirror image All operations are on binary files no need development environment(offline) Set the u-boot environment on binary image Windows OS support Snapshot: Please download create_sdcard_mirror_ext.zip.001.zip create_sdcard_mirror_ext.zip.002.zip create_sdcard_mirror_ext.zip.003.zip create_sdcard_mirror_ext.zip.004.zip create_sdcard_mirror_ext.zip.005.zip create_sdcard_mirror_ext.zip.006.zip extract each one to have below files create_sdcard_mirror_ext.zip.001 create_sdcard_mirror_ext.zip.002 create_sdcard_mirror_ext.zip.003 create_sdcard_mirror_ext.zip.004 create_sdcard_mirror_ext.zip.005 create_sdcard_mirror_ext.zip.006 Put together and extract them.

Kernel provides mtdoops to dump kmsg to MTD device, but MMC card is not a MTD device. We can let user-space program to execute the write operation to dump kmsg into block storage. The sample code is below. kernel space -- #include <linux/kernel.h> #include <linux/module.h> #include <linux/console.h> #include <linux/vmalloc.h> #include <linux/seq_file.h> #include <linux/workqueue.h> #include <linux/sched.h> #include <linux/wait.h> #include <linux/delay.h> #include <linux/interrupt.h> #include <linux/kmsg_dump.h> #include <linux/proc_fs.h> static struct kmsg_dumper dump; static struct proc_dir_entry *my_proc; static int is_panic = 0; static int my_proc_show(struct seq_file *m, void *v) { seq_printf(m, "%d", is_panic); return 0; } static int my_proc_open(struct inode *inode, struct file *file) { return single_open(file, my_proc_show, NULL); } static const struct file_operations my_proc_ops = { .open = my_proc_open, .read = seq_read, .llseek = seq_lseek, .release = single_release, }; static void oops_do_dump(struct kmsg_dumper *dumper, enum kmsg_dump_reason reason, const char *s1, unsigned long l1, const char *s2, unsigned long l2) { int i; printk("### [%s:%d] reason = %d\n", __func__, __LINE__, reason); is_panic = 1; for (i = 0;i < 10; i++) msleep(1000); printk("### [%s:%d] should be done\n", __func__, __LINE__); } static int __init my_oops_init(void) { int err; dump.dump = oops_do_dump; err = kmsg_dump_register(&dump); if (err) { printk(KERN_ERR "oops: registering kmsg dumper failed, error %d\n", err); return -EINVAL; } my_proc = proc_create("dump_tester", 0, NULL, &my_proc_ops); return 0; } static void __exit my_oops_exit(void) { printk("### [%s:%d]\n", __func__, __LINE__); if (my_proc) remove_proc_entry( "dump_tester", NULL); kmsg_dump_unregister(&dump); } module_init(my_oops_init); module_exit(my_oops_exit); MODULE_LICENSE("GPL"); User space -- #include <stdio.h> #include <stdlib.h> #include <string.h> #include <sys/types.h> #include <sys/stat.h> #include <unistd.h> #include <fcntl.h> #include <poll.h> #define BUF_LEN 40960 void main(int argc, char **argv) { char tmp = 'X'; char buf[BUF_LEN]; int fd_src, fd_trg; int fd = open("/proc/dump_tester", O_RDONLY, 0); while(1) { lseek(fd, 0, SEEK_SET); read(fd, &tmp, 1); //printf("### [%s:%d] ==> '%c'\n", __FUNCTION__, __LINE__, tmp); if (tmp == '1') { fd_src = open("/proc/kmsg", O_RDONLY, 0); fd_trg = open("/dev/block/mmcblk0p6", O_RDWR, 0); memset(buf, 0, BUF_LEN); write(fd_trg, buf, BUF_LEN); lseek(fd_trg, 0, SEEK_SET); read(fd_src, buf, BUF_LEN); write(fd_trg, buf, BUF_LEN); close(fd_src); close(fd_trg); sleep(1); printf("### dump panic log into %s\n", "/dev/block/mmcblk0p6"); break; } sleep(1); } close(fd); }

Recently, some customers are using i.MX processor, they want to add raid & LVM function support to the kernel, but they have encountered the problem that the compilation cannot pass. Tested it in L4.14.98, L4.19.35 & L5.4.x, Only L4.14.98 bsp exists the problem. Here are the experimental steps I have done, including the same problems I encountered with the customer, and how to modify the kernel to ensure that the compilation passes. 1. Exporting cross compilation tool chain from yocto BSP (1) Downloading Yocto BSP and compiling it. Following steps in i.MX_Yocto_Project_User's_Guide.pdf, download Yocto BSP and compile it successfully. (2) Exporting cross compilation tool chain Following methods described in i.MX_Linux_User's_Guide.pdf, export cross compilation tool chain from yocto BSP. See Chapter 4.5.12 of the document, please! Then cross compilation tool chain will be like below: 1.png (3) Copying linux BSP source code to a new directory # cd ~ # mkdir L4.14.98-2.0.0 # cd L4.14.98-2.0.0 # cp -r ~/imx-yocto-bsp/build-fb/tmp/work/imx6qsabresd-poky-linux-gnueabi/linux-imx/4.14.98- r0/git ./ Then all linux source code has been copied to L4.14.98-2.0.0, which is the top directory of linux kernel source code, I will compile kernel image here. 2. Compiling linux kernel # cd ~/L4.14.98-2.0.0 # source /opt/fsl-imx-fb/4.14-sumo/environment-setup-cortexa9hf-neon-poky-linux-gnueabi # export ARCH=arm # make imx_v7_defconfig # make menuconfig Then we will add RAID and LVM modules to linux kernel. In order to reproduce errors, I added all related modules to kernel. See below, please! Device drivers---->Multiple devices driver support (RAID and LVM) 2.png After save and exit, began to compile kernel. # make (make –j4) The following errors will occur: ------------------------------------------------------------------------------------------- drivers/md/dm-rq.c: In function ‘dm_old_init_request_queue’: drivers/md/dm-rq.c:716:2: error: implicit declaration of function ‘elv_register_queue’; did you mean ‘blk_register_queue’? [-Werror=implicit-function-declaration] elv_register_queue(md->queue); ^~~~~~~~~~~~~~~~~~ blk_register_queue cc1: some warnings being treated as errors scripts/Makefile.build:326: recipe for target 'drivers/md/dm-rq.o' failed make[2]: *** [drivers/md/dm-rq.o] Error 1 scripts/Makefile.build:585: recipe for target 'drivers/md' failed make[1]: *** [drivers/md] Error 2 Makefile:1039: recipe for target 'drivers' failed make: *** [drivers] Error 2 ------------------------------------------------------------------------------------------- 3. Finding out root cause and solving it (1) elv_register_queue( ) function The function is loaded in dm-rq.c : int dm_old_init_request_queue(struct mapped_device *md, struct dm_table *t) { … … elv_register_queue(md->queue); … … } BUT compiler didn’t find it’s declaration and entity. Searching source code, and found it declared in linux_top/block/blk.h: … … int elv_register_queue(struct request_queue *q); … … It’s entity is in linux_top/block/elevator.c: int elv_register_queue(struct request_queue *q) { … … } (2) Adding declaration and exporting the function --- Declaration Add the line below to dm-rq.c: … … extern int elv_register_queue(struct request_queue *q); … … --- Exporting the function(elevator.c) Add EXPORT_SYMBOL(elv_register_queue); to the end of function, see below. int elv_register_queue(struct request_queue *q) { … … } EXPORT_SYMBOL(elv_register_queue); 4. Re-compiling Linux Kernel The above error will not occur and the compilation will complete successfully. NXP CAS team Weidong Sun

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

About this document This document describe the setup detail for Interfacing, Installing, programming (basis) and testing depth cameras with MX6QDL based boards using Ubuntu as rootfs on i.MX6 processors boards. 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 Depth sensors tested: Microsoft Kinect, ASUS Xtion. Prime Sense Carmine Software: Gcc, Ubuntu 14.04v, Openni, Python, ROS. 1. Depth Sensor Depth sensors are 3D vision sensors, mainly used in 3D vision application and motion gaming and robotics. For this paper we are going to use Kinect sensor and Asus Xtion connection to i.MX6 Processor boards and will get 3D images that are converted to finer points called point cloud. a) Microsoft Kinect Kinect mainly has an IR camera, IR projector and RGB camera, the IR and projector generates the 3D point cloud of the surroundings. It also has a mic array and motorized tilt for moving up and down. Kinect reveal that both the video and depth sensor cameras have a 640 x 480-pixel resolution and run at 30 FPS (frames per second). The RGB camera capture 2D color images, whereas the depth camera captures monochrome depth images. Kinect has a depth sensing range from 0.8mts to 3.5 mts b) Asus Xtion: Another alternative to kinect is Asus Xtion Pro. Is a 3D sensor designed for motion sensing applications, this sensor is only for 3D sensing and it doesn’t have sound sensing. It has an infrared projector and a monochrome CMOS sensor to capture the infrared data. Xtion can be powered from USB itself and can calculate a sense depth from 0.8mts to 3.5 mts from the sensor. c) Prime Sense Carmine: The Prime Sense team (apple bought this company in November 2013) developed the Microsoft Kinect 3D vision, later develop their own 3D vision sensor Carmine. It also works with IR projector, RGB CMOS sensor and a depth CMOS sensor. All sensor are interfaced in System On Chip and is powered trough USB. Carmine capture 640x480 at 30 FPS and can sense from 0.35 mts to 3 mts. Developers can program the device using OpenNI and its wrapper libraries. All these sensors (Kinect, Carmine and Xtion) support the same software, so there is no special need for programming or general usage. Can be interface to i.MX processor using USB 2.0 interface and programmed using OPENNI and OPENCV. 2. Installation on Ubuntu For installation steps of Ubuntu trusty on iMX6 boards in your board, please follow up: https://community.freescale.com/docs/DOC-330147 Install the dependencies: $ sudo apt-get install -y g++ git python libusb-1.0-0-dev libudev-dev freeglut3-dev doxygen graphviz openjdk-6-jdk libxmu-dev libxi-dev Create a devel folder $ sudo mkdir –p devel $ cd devel Get OpenNI and the drivers $ git clone https://github.com/OpenNI/OpenNI.git -b unstable $ git clone git://github.com/ph4m/SensorKinect.git $ git clone https://github.com/PrimeSense/Sensor.git -b unstable Set the compile flags to build for the i.MX $ nano OpenNI/Platform/Linux/CreateRedist/Redist_OpenNi.py From: MAKE_ARGS += ' -j' + calc_jobs_number() To: MAKE_ARGS += ' –j2' Must also change the Arm compiler settings for this distribution $ nano OpenNI/Platform/Linux/Build/Common/Platform.Arm From: CFLAGS += -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp #-mcpu=cortex-a8 To: CFLAGS += -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard Then run $ cd OpenNI/Platform/Linux/CreateRedist/ $ ./RedistMaker.Arm $ cd ../Redist/OpenNI-Bin-Dev-Linux-Arm-v1.5.x.x $ sudo ./install.sh Also edit the Sensor and SensorKinect makefile CFLAGS parameters $cd ~/devel/ $ nano Sensor/Platform/Linux/Build/Common/Platform.Arm $ nano SensorKinect/Platform/Linux/Build/Common/Platform.Arm For both files From: CFLAGS += -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp #-mcpu=cortex-a8 To: CFLAGS += -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard And the Sensor and SensorKinect redistribution scripts $ nano Sensor/Platform/Linux/CreateRedist/RedistMaker $ nano SensorKinect/Platform/Linux/CreateRedist/RedistMaker for both, change: make -j$(calc_jobs_number) -C ../Build to: make –j2 -C ../Build The create the redistributables Sensor (xtion and primesense) and Kinect (sensor Kinect) $ cd Sensor/Platform/Linux/CreateRedist/ $ ./RedistMaker Arm $ cd ~/devel/ $ cd SensorKinect/Platform/Linux/CreateRedist/ $ ./RedistMaker Arm $ cd ~/devel/ Then install PrimeSense and Kinect $ cd Sensor/Platform/Linux/Redist/Sensor-Bin-Linux-Arm-v5.1.x.x $ sudo ./install.sh $ cd ~/devel/SensorKinect/Platform/Linux/Redist/Sensor-Bin-Linux-Arm-v5.1.2.x $ sudo ./install.sh 3. Testing Installation: Connect the sensor power supply, Connect the Kinect to the NXP board USB port. (check with lsusb). For my board: Imx6q@imx6q:~/devel$ lsusb Bus 001 Device 022: ID 045e:02ae Microsoft Corp. Xbox NUI Camera Bus 001 Device 021: ID 045e:02ad Microsoft Corp. Xbox NUI Audio Bus 001 Device 019: ID 045e:02c2 Microsoft Corp. Kinect for Windows NUI Motor Now edit theglobal Kinect settings in Ubuntu $ sudo nano /usr/etc/primesense/GlobalDefaultsKinect.ini and uncomment this line UsbInterface=1 and changed it to 1 instead of 2 UsbInterface=2 $ sudo modprobe -r gspca_kinect And then blacklisting to avoid it to be auto-loaded on boot: $ sudo sh -c 'echo "blacklist gspca_kinect" > /etc/modprobe.d/blacklist-kinect.conf' Then: $ cd ~/devel/OpenNI/Platform/Linux/Bin/Arm-Release $ sudo ./Sample-NiSimpleRead You should get something like: Reading config from: '../../../../Data/SamplesConfig.xml' … Frame 40 Middle point is: 5050. FPS: 30.771788 Frame 41 Middle point is: 5050. FPS: 30.866173 Frame 42 Middle point is: 5050. FPS: 30.850958 Frame 43 Middle point is: 5050. FPS: 30.779032 Frame 44 Middle point is: 5050. FPS: 30.767746 Frame 45 Middle point is: 5050. FPS: 30.800463 Frame 46 Middle point is: 5050. FPS: 30.653118 Frame 47 Middle point is: 5050. FPS: 30.741659 Frame 98 Middle point is: 5050. FPS: 30.339321 LibFreenect: $ cd ~/devel/ $ git clone https://github.com/OpenKinect/libfreenect.git $ cd libfreenect $ mkdir build $ cd build $ cmake .. –L –DBUILD_AUDIO=ON $ make $ sudo make install Connect the kinect sensor power supply, connect the Kinect to the NXP board USB port and test any sample such as: $ sudo freenect-glview Note: If glview gives a shared library error: You need to refresh your ldconfig cache. The easiest way to do this is to create a file usr-local-libs.conf (or whatever name you wish) with the following lines: /usr/local/lib Switch to root account and move it to /etc/ld.so.conf.d/usr-local-libs.conf. Then update the ldconfig cache: $ su root $ mv ~/usr-local-libs.conf /etc/ld.so.conf.d/usr-local-libs.conf $ /sbin/ldconfig –v $ exit References: 1) https://openkinect.org/ 2) https://www.asus.com/us/3D-Sensor/Xtion_PRO_LIVE/ 3) Learning Robotics using phyton by Lentin Joseph. http://www.amazon.com/Learning-Robotics-Python-Lentin-Joseph/dp/1783287535/ref=sr_1_1 4) Computer Vision on i.MX Processors

The i.MX 6 D/Q/DL/S/SL Linux 3.10.17_1.0.1 patch release is now available in the Freescale git. The issue fixed is a GPU issue, for 2D GPU cores there is a potential need to manage the maximum number of outstanding return requests from the memory subsystem. The proper way to manage these for 2D cores with this configuration is to use a FLUSH. The patch does a FLUSH after every DRAW, the pipe will not overfill and the scenario which may lead to a stall will not occur. The instruction to get the patch are in the Readme on the git, under this link: http://git.freescale.com/git/cgit.cgi/imx/fsl-arm-yocto-bsp.git/tree/README?h=imx-3.10.17-1.0.1_ga

This guide provides a step-by-step approach for beginners looking to flash a custom Kernel Image or device tree on an NXP i.MX board. Sometimes, we need to customize the Kernel Image or modify the device tree for our board. Fortunately, NXP provides the UUU (Universal Update Utility) tool, which allows us to flash and use a custom Kernel Image or update the device tree on our board. Requirements Before proceeding, ensure you have the following: - The latest version of the UUU Tool. - An i.MX EVK board (i.MX6, i.MX7, i.MX8, i.MX9). - The power supply for the board. - Two USB cables (USB-C or Micro USB, depending on your board). Preliminary Steps To customize the Kernel Image or device tree, refer to the following community posts: - How to Fix FRDM-IMX93 Linux Kernel BSP - How to Compile Linux Kernel Image and Device Tree Using Yocto SDK Once you have your customized Linux Kernel Image or device tree ready, follow the steps below to deploy it to your board. Flashing the Kernel Image or Device Tree Connect and Prepare the Board 1. Connect the USB debug cable and the OTG cable from your board to your host computer. 2. Power on your board and stop the boot process at the U-Boot stage by pressing a key in the terminal. 3. Enter fastboot mode by running the following command in the U-Boot terminal: u-boot -> fastboot 0 Flash the Custom Kernel Image or Device Tree 4. Open a terminal on your host computer and navigate to the directory containing the new Kernel Image or device tree. 5. Flash the new files using the following command: $ uuu -b fat_write <file_name> mmc <device>:<partition> <file_name_in_board> Example: $ uuu -b fat_write imx93-11x11-evk.dtb mmc 0:1 imx93-11x11-evk-custom.dtb In this example, the file imx93-11x11-evk.dtb stored on the host machine is flashed to the board's eMMC device, saving it as imx93-11x11-evk-custom.dtb. Note: If you are using Linux, run the command with sudo. - For eMMC and SD card, the command is the same; just ensure you use the correct device number. - On the i.MX93, device 0 corresponds to eMMC, and device 1 corresponds to the SD card. Update U-Boot Environment Variables 6. Exit fastboot mode by pressing CTRL+C. This returns you to the U-Boot terminal. 7. Set up the environment variablesto use the new files: For the Kernel Image: u-boot -> setenv image <custom_image_name> u-boot -> saveenv u-boot -> reset For the Device Tree: u-boot -> setenv fdtfile <custom_device_tree_name> u-boot -> saveenv u-boot -> reset The board should now boot using your modified Kernel Image and device tree.

this is tested with MX93(A1) EVK running 6.1.55_2.2.0 pre-build image. USB can output test patterns with either one of the setup below: 1. through device node: root@imx93evk:/sys/kernel/debug/usb/ci_hdrc.0# cat role gadget root@imx93evk:/sys/kernel/debug/usb/ci_hdrc.0# echo host > role [ 2672.864083] ci_hdrc ci_hdrc.0: EHCI Host Controller [ 2672.868996] ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 1 [ 2672.893320] ci_hdrc ci_hdrc.0: USB 2.0 started, EHCI 1.00 [ 2672.899314] hub 1-0:1.0: USB hub found [ 2672.909235] hub 1-0:1.0: 1 port detected root@imx93evk:/sys/kernel/debug/usb/ci_hdrc.0# cat role host root@imx93evk:/sys/kernel/debug/usb/ci_hdrc.0# echo 4 > port_test root@imx93evk:/sys/kernel/debug/usb/ci_hdrc.0# echo 3 > port_test root@imx93evk:/sys/kernel/debug/usb/ci_hdrc.0# echo 2 > port_test root@imx93evk:/sys/kernel/debug/usb/ci_hdrc.0# echo 1 > port_test 2. use memtool to program registers for i in $(find /sys -name control | grep usb);do echo on > $i;echo "echo on > $i";done; echo host > /sys/kernel/debug/usb/ci_hdrc.0/role #Offset:184h USB_OTG1 base address: 4C10_0000h base address USB_OTG2 base address: 4C20_0000h Register address Register address：base address+offset $ /unit_tests/memtool 0x4c100184 1 # Force to output Test Packet for Eye Diagram Test $ /unit_tests/memtool 0x4c100184=0x18041215 #Force to output J_STATE $ /unit_tests/memtool 0x4c100184=0x18011215 #Force to output K_STATE $ /unit_tests/memtool 0x4c100184=0x18021215 #Force to output SE0 (host) / NAK (device) $ /unit_tests/memtool 0x4c100184=0x18031215

In this article, I will explain how to set up the iMX8M Plus to use the 4K Dart BCON Basler Camera module. imx8mp.png Requirements: Evaluation Kit for the i.MX 8M Plus Applications Processor. (i.MX 8M Plus Evaluation Kit | NXP Semiconductors) Basler Camera for i.MX 8M Plus (4K dart BCON for MIPI camera module for i.MX 8M Plus | NXP Semiconductors). Embedded Linux for i.MX Applications Processors (Embedded Linux for i.MX Applications Processors | NXP Semiconductors) (For this example we will use BSP version Linux 5.15.71_2.2.0) Serial Console Emulator Basler Camera Specifications and Manuals: Basler Camera Specifications at this link: Embedded Vision Kits daA3840-30mc-IMX8MP-EVK - Embedded Vision Kits (baslerweb.com). Basler Manual to identify and setting up the hardware at this link: daA3840-30mc-IMX8MP-EVK | Basler Product Documentation (baslerweb.com) Basler Camera Module out-of-box with i.MX 8M Plus Applications Processor. (Video: Basler Camera Module out-of-box with i.MX 8M Plus Applications Processor | NXP Semiconductors) Steps After setting up the hardware we will need to turn on the iMX8M Plus and follow these steps: 1. Stop the boot process on Uboot by pressing any key. 2. Use the following command to list interfaces. => mmc list Output example => FSL_SDHC: 1 (SD) => FSL_SDHC: 2 The above command will show you the device number in this example for SD, the device number is 1. 3. Then use fatls <interface> <device[:partition]> [<directory>] fatls mmc 1:1 (Device 1 : Partition 1) With this command, we will be able to list device tree files. => fatls mmc 1:1 4. Select imx8mp-evk-basler.dtb or imx8mp-evk-dual-basler.dtb and use the command editenv fdtfile. => editenv fdtfile Output example edit: imx8mp-evk-basler.dtb 5. In edit command line put the selected device tree (*.dtb). 6. Use saveenv command to save environment and continue with the boot process. 7. Using the terminal and go to /opt/imx8-isp/bin and execute the script run.sh. $ ./run.sh -c basler_1080p60 -lm 8. Use the command gst-device-monitor-1.0 to list devices. Here you will find the path to the camera device. $ gst-device-monitor-1.0 Output example Device found: name : VIV class : Video/Source caps : video/x-raw, format=YUY2, width=[ 176, 4096, 16 ], height=[ 144, 3072, 8 ], pixel-aspect-ratio=1/1, framerate={ (fraction)30/1, (fraction)29/1, (fraction)28/1, (fraction)27/1, (fraction)26/1, (fraction)25/1, (fraction)24/1, (fraction)23/1, (fraction)22/1, (fraction)21/1, (fraction)20/1, (fraction)19/1, (fraction)18/1, (fraction)17/1, (fraction)16/1, (fraction)15/1, (fraction)14/1, (fraction)13/1, (fraction)12/1, (fraction)11/1, (fraction)10/1, (fraction)9/1, (fraction)8/1, (fraction)7/1, (fraction)6/1, (fraction)5/1, (fraction)4/1, (fraction)3/1, (fraction)2/1, (fraction)1/1 } ... properties: udev-probed = true device.bus_path = platform-vvcam-video.0 sysfs.path = /sys/devices/platform/vvcam-video.0/video4linux/video2 device.subsystem = video4linux device.product.name = VIV device.capabilities = :capture: device.api = v4l2 device.path = /dev/video2 v4l2.device.driver = viv_v4l2_device v4l2.device.card = VIV v4l2.device.bus_info = platform:viv0 v4l2.device.version = 393473 (0x00060101) v4l2.device.capabilities = 2216693761 (0x84201001) v4l2.device.device_caps = 69206017 (0x04200001) gst-launch-1.0 v4l2src device=/dev/video2 ! ... 9. Finally, use gstreamer to verify proper operation. (With this gstreamer pipeline you will see a new window with the camera output. Then, just rotate the lens to acquire the correct focus) $ gst-launch-1.0 -v v4l2src device=/dev/video2 ! "video/x-raw,format=YUY2,width=1920,height=1080" ! queue ! imxvideoconvert_g2d ! waylandsink Basic description of Gstreamer Pipeline gst-launch-1.0 -v: The option -v enables the verbose mode to get detailed information of process. v4l2src device=/dev/video2: Select input device in this case the camera is on path /dev/video3. "video/x-raw,format=YUY2,width=1920,height=1080": Received format from camera. queue: This command is a buffer between camera recording process and the following image process, this command help us to interface two process and prevent blocking where each process has different speeds, in other words, when a process A is faster than process B. imxvideoconvert_g2d: This proprietary plugin uses hardware acceleration to perform rotation, scaling, and color space conversion on video frames. waylandsink : This command creates its own window and renders the decoded frames processed previously. 10. Result Screenshot (46).png I hope this article will be helpful. Best regards, Brian.

meta-avs-demos Yocto layer meta-avs-demos is a Yocto meta layer (complementary to the NXP BSP release for i.MX) published on CodeAurora that includes the additional required packages to support Amazon's Alexa Voice Services SDK (AVS_SDK) applications. The build procedure is the described on the README.md of the corresponding branch. We have 2 fuctional branches now: imx-alexa-sdk: Support for Morty based i.mx releases imx7d-pico-avs-sdk_4.1.15-1.0.0: legacy support for Jethro releases The master branch is only used to collect manifest files, that used with repo init/sync commands will fetch the whole environment for the 2 special supported boards: i.MX7D Pico Pi and i.MX8M EVK. However the meta-avs-demos can be used with any i.MX board either. Recipes to include Amazon's Alexa Voice Services in your applications. The meta-avs-demos provides the required recipes to build an i.MX image with the support for running Alexa SDK. The imx-alexa-sdk branch is based on Morty and kernel 4.9.X and it supports the next builds: i.MX7D Pico Pi i.MX8M EVK Generic i.MX board For the i.MX7D Pico Pi and i.MX8M EVK there is an extended support for additional (external) Sound Cards like: TechNexion VoiceHat: 2Mic Array board with DSPConcepts SW support Synaptics Card: 2 Mic with Sensory WakeWord support The Generic i.MX is for any other regular i.MX board supported on the official NXP BSP releases. Only the default soundcard (embedded) on the board is supported. Sensory wakeword is currently only enabled for those with ARMV7 architecture. To support any external board like the VoiceHat or Synaptics is up to the user to include the additional patches/changes required. Build Instructions Follow the corresponding README file to follow the steps to build an image with Alexa SDK support README-IMX7D-PICOPI.md README-IMX8M-EVK.md README-IMX-GENERIC.md

About this document This document describe the setup detail for Interfacing, Installing, programming (basis) and testing depth cameras with MX6QDL based boards using the Robotic Operating System (ROS). If you are not using ROS you can also install the proper drivers and compile, in your Ubuntu system as explained on document: https://community.freescale.com/docs/DOC-330278 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 Depth sensors tested: Microsoft Kinect, ASUS Xtion. Software: Gcc, Ubuntu 14.04v, OpenCV, Openni, Python, ROS. 2. Installation on ROS For installation steps of ROS on iMX6 boards in your board, please follow up: https://community.freescale.com/docs/DOC-3301478 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 There are many different libraries and tools in ROS - not all compile fully on ARM. In this case we already have installed the ROS Base, however any other packages need to be installed individually. First install the following dependencies, which will take some time and space (~1.4 GB): $ sudo apt-get install --no-install-recommends freeglut3-dev libfreenect-dev libusb-1.0-0-dev libudev-dev ros-indigo-camera-info-manager ros-indigo-dynamic-reconfigure ros-indigo-image-transport ros-indigo-image-proc ros-indigo-depth-image-proc ros-indigo-tf ros-indigo-openni-launch ros-indigo-freenect-* ros-indigo-depthimage-to-laserscan ros-indigo-image-view ros-indigo-camera-info-manager ros-indigo-dynamic-reconfigure libudev-dev doxygen graphviz openjdk-6-jdk ros-indigo-openni2-camera ros-indigo-openni2-launch ros-indigo-rqt-common-plugins ros-indigo-rqt-graph There is no any additional installation to run kinect with ROS, If you are using kinect you can pass to part 4. However the packages used to run the PrimeSense / Asus Xtion on the i.Mx6 are not available over apt yet, so they need to be compiled from source. To use OpenNI2 with ROS, we only need the shared OpenNI2 libraries and the Drivers. Clone OpenNI2 $ git clone https://github.com/OpenNI/OpenNI2 $ cd OpenNI2 Edit ThirdParty/PSCommon/BuildSystem/Platform.Arm $ nano ThirdParty/PSCommon/BuildSystem/Platform.Arm and replace CFLAGS += -march=armv7-a -mtune=cortex-a9 -mfpu=neon -mfloat-abi=softfp #-mcpu=cortex-a8 with CFLAGS += -march=armv7-a -mtune=cortex-a9 -mfpu=neon -mfloat-abi=hard Add support for pthread library: $ nano ThirdParty/PSCommon/BuildSystem/CommonCppMakefile Search the line 95 and add the code between the two lines: OUTPUT_NAME = $(EXE_NAME) # We want the executables to look for the .so's locally first: LDFLAGS += -Wl,-rpath ./ + ifneq ("$(OSTYPE)","Darwin") + LDFLAGS += -lpthread + endif OUTPUT_COMMAND = $(CXX) -o $(OUTPUT_FILE) $(OBJ_FILES) $(LDFLAGS) endif Save the file and exit Then run make to compile the OpenNI2 drivers and libraries $ PLATFORM=Arm make ALLOW_WARNINGS=1 Once the compilation is done, run the linux install script $ cd Packaging/Linux $ sudo ./install.sh Copy libraries and includes to the system paths $ cd ../../ $ sudo cp -r Include /usr/include/openni2 $ sudo cp -r Bin/Arm-Release/OpenNI2 /usr/lib/ $ sudo cp Bin/Arm-Release/libOpenNI2.* /usr/lib/ Create a package config file $ sudo nano /usr/lib/pkgconfig/libopenni2.pc and fill it with this: prefix=/usr exec_prefix=${prefix} libdir=${exec_prefix}/lib includedir=${prefix}/include/openni2 Name: OpenNI2 Description: A general purpose driver for all OpenNI cameras. Version: 2.2.0.0 Cflags: -I${includedir} Libs: -L${libdir} -lOpenNI2 -L${libdir}/OpenNI2/Drivers -lDummyDevice -lOniFile -lPS1080.so This will enable ubuntu to find the location of the drivers, libraries and include files. To make sure it is correctly found, run $ pkg-config --modversion libopenni2 Which should give the same version as defined in the file above (2.2.0.0). Now the Xtion is ready to be used. Plug it in (if it is already, unplug it first), then run the sample program $ ./Bin/Arm-Release/SimpleRead Then create a catkin workspace as described here, and check out the following packages in the src folder of the catkin workspace: $ cd ~/catkin_ws/src $ git clone https://github.com/ros-drivers/openni2_camera $ git clone https://github.com/ros-drivers/openni2_launch $ git clone https://github.com/ros-drivers/rgbd_launch Now the ros packages checked out above to the catkin workspace can be compiled with catkin_make $ cd ~/catkin_ws $ catkin_make Once the packages are compiled, the Xtion is ready for use with ROS with 3. Testing The Installation Kinect. Open at least 3 bash terminals: Terminal 1: Run ROS $ roscore Terminal 2: launch the Freenect $ roslaunch freenect_launch freenect.launch Terminal 3: run the image capture $ rosrun image_view image_view image:=camera/rgb/image_color or: $ rosrun image_view image_view image:=camera/rgb/image_rect_mono or: $ rosrun image_view disparity_view image:=camera/depth/disparity It will open a new terminal with the rgb points, mono and depth images from the Kinect. Xtion. Terminal 1: Run ROS $ roscore Terminal 2: launch Openni2 $ roslaun openi2_launch openni2.launch Terminal 3: you can use rqt or Rviz session to visualize the sensor e.g: $ rqt or $ rosrun rqt_graph rqt_graph In the “rqt” window select “Plugins” -> “Visualization” -> “Image View“ (optional) Install PySide, in any case you get an error with python rqt graph: $ pip install PySide $ cd ~/ Note: rqt and Rviz demand a lot of i.MX GPU work, so general graphic functionality will be affected. For this case is suggested to run rviz in a remote Network ROS session. References: - www.ros.org - https://dobots.nl/2014/05/05/asus-xtion-using-openni2-and-ros-on-udoo/

Two year ago we have developed a 16 bit ETM adaptor to connect our PowerTrace II module with our AUTOFOCUS II preprocessor : TRACE32® Chip Support and Configurations for IMX6QUAD This adaptor is connected on the EDGE connector of the SABRE Automotive Industry board from Freescale and provide a MICTOR 38 connector compatible with 16 bit maximum ETM size. This is the maximum ETM size supported by iMX6. The maximum Trace clock frequency riched is 132 Mhz, which provide enough bandwidth to trace a full ANDROID running on Quad Core iMX6 !!! and it works perfectly. with Lauterbach tools you can debug completely Linux kernel and driver and full ANDROID support using our dalvik awareness that show you the complete call stack from low level system linux call to high level JAVA code. this adaptor is already in use on several customer from us, with perfect result. TRACE32 can now display all the code executed by the iMX6 Quad for each core, with no limitation on time recording. Linux task switch timing, profiling function, MIPS information, Detailed Tree function etc ... more detail here : TRACE32® Trace-based Profiling here below a small example of what you can see : here below the board, and schematic. in case you want the full schematic for this adaptor, please contact me, i can then provide it for free ... if you buy some Lauterbach tools 😉 Jean-Pierre Paradiso Sales Manager http://www.lauterbach.com/frames.html?tutorials.html PS : we are also developping a new ETM adapter compatible with our partner DAVE (DAVE Embedded Systems ) that develop very nice eval board on iMX6 called AXEL EVB will be available soon through the official DAVE distributor in France : Cynetis

Hi all, Most of IoT customers request to enable/demo i.MX EVK with FSL Zigbee solution. In default i.MX Linux/Android BSP, Zigbee function is not enabled. Here we make a lighting demo setup through i.MX6Q SabreSD, KW20 USB dongle and Philips Hue light. KW20 is configured as Zigbee coordinator, connected with USB OTG in i.MX6Q, then i.MX6Q can issue On/Off, brightness and color control commands through KW20 to toggle Philips Hue light directly. Please find the attachment for details. Best regards, Carl

The attached is the document and sample code for iMX5 system 80 interface LCD driver based on IPUV3. It is based on iMX51 2.6.31_09.12 BSP (SDK 1.7), tested on iMX53 3-Stack board. 1. Description This is Smartlcd driver for Freescale MX51 SDK1.7 release. (Kernel: 2.6.31_09.12.00/01) 2. File List -- Smartlcd_giantplus_4_IMX51_Linux_2.6.31_09.12.01.patch: SmartLCD panel support patch, and unit test code. -- Sample.config: the config file for reference. -- readme.txt: this file, please refer to it before use the package. -- SmartLCD Structure.pptx: the basic structure for smartlcd on IPUv3. 3. Requirement - MX51_3DS Green board(TO2.0) - No hardware rework needed, only need plug the giantplus GMA722A0 to J10. - MX51 SDK1.7 release package - L2.6.31_09.12.00_SDK_source.tar.gz - redboot_200952.zip 4. How to use 4.1 How to use demo -- Program default redboot.bin to board via ATKtools -- Copy attached zImage to tftp folder (assume /tftpboot) -- extract default rootfs to NFS folder (assume /nfsroot) -- COPY attached imx51_fb_test to ~/unit_test folder. -- Power on the board -- After redboot is boot up, use following command to boot up linux kernel load -r -b 0x100000 zImage exec -c "noinitrd console=ttymxc0 root=/dev/nfsroot rootfstype=nfsroot nfsroot=10.192.225.221:/nfsroot/rootfs rw ip=dhcp" -- Once the linux kernel launched, run following commands to test smartlcd panel. cd /unit_tests ./imx51_fb_test 4.2 How to use source code -- Current release code is based on L2.6.31_09.12.00_SDK_source.tar.gz. Extract the file to your working folder. -- Entering the working folder and type "./install", select a folder to install ltib. (such as .../ltib) -- Entering ltib folder and type "./ltib" to build Linux platform. If you are not familiar with this setp, please refer to doc "i.MX_3Stack_SDK_UserGuide.pdf" for detail. -- Entering folder ".../ltib/rpm/BUILD/linux", copy "Smartlcd_giantplus_4_IMX51_Linux_2.6.31_09.12.01.patch" from release package to current folder Run command "patch -p1 < Smartlcd_giantplus_4_IMX51_Linux_2.6.31_09.12.01.patch" -- When complete, run command "make ARCH=arm menuconfig", and you can refer to attached sample.config for detail. * enable Device Drivers ----> Graphics support ----> [*] Asynchronous Panels ----> [*] GiantPlus 240x320 Panel * disable Device Drivers ----> Graphics support ----> [ ] Synchronous Panel Framebuffer ----> Multimedia support ----> [ ] Video For Linux -- Run command "make ARCH=arm" to build kernel. 4.3 How to do SMARTLCD driver test -- After Smartlcd_giantplus_4_IMX51_Linux_2.6.31_09.12.01.patch applied, there will be an folder "IMX51_TEST" under linux. -- Go to that folder, and run "make ARCH=arm", imx51_fb_test will be created. -- Copy imx51_fb_test to rootfs/unit_test. and run. 5. History N/A 6. Known Issue -- V4L2 not working yet.

Instead to use gst-launch to play your audio/video media you can create an application do to that. This application was tested in iMX27ADS but should to work on iMX27PDK First execute LTIB (./ltib -c) and select these packages: all gstreamer plugin, alsa-utils and libmad. Create your file code (i.e.: playvideo.c): #include <gst/gst.h> #include <glib.h> #include <string.h> static GstElement *source, *demuxer, *vdqueue, *adqueue, *vdsink, *adsink, *decvd, *decad; void on_pad_added (GstElement *element, GstPad *pad) { g_debug ("Signal: pad-added"); GstCaps *caps; GstStructure *str; caps = gst_pad_get_caps (pad); g_assert (caps != NULL); str = gst_caps_get_structure (caps, 0); g_assert (str != NULL); if (g_strrstr (gst_structure_get_name (str), "video")) { g_debug ("Linking video pad to dec_vd"); // Link it actually GstPad *targetsink = gst_element_get_pad (decvd, "sink"); g_assert (targetsink != NULL); gst_pad_link (pad, targetsink); gst_object_unref (targetsink); } if (g_strrstr (gst_structure_get_name (str), "audio")) { g_debug ("Linking audio pad to dec_ad"); // Link it actually GstPad *targetsink = gst_element_get_pad (decad, "sink"); g_assert (targetsink != NULL); gst_pad_link (pad, targetsink); gst_object_unref (targetsink); } gst_caps_unref (caps); } 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; GstBus *bus; /* Initialisation */ gst_init (&argc, &argv); loop = g_main_loop_new (NULL, FALSE); /* Check input arguments */ if (argc != 2) { g_printerr ("Usage: %s <Video H264 filename>\n", argv[0]); return -1; } /* Create gstreamer elements */ pipeline = gst_pipeline_new ("media-player"); source = gst_element_factory_make ("filesrc","file-source"); demuxer = gst_element_factory_make ("mfw_mp4demuxer","avi-demuxer"); decvd = gst_element_factory_make ("mfw_vpudecoder", "video-decoder"); decad = gst_element_factory_make ("mad", "mp3-decoder"); vdsink = gst_element_factory_make ("mfw_v4lsink", "video-sink"); vdqueue = gst_element_factory_make ("queue", "video-queue"); adqueue = gst_element_factory_make ("queue", "audio-queue"); adsink = gst_element_factory_make ("fakesink", "audio-sink"); g_object_set (decvd, "codec-type", "std_avc", NULL); if (!pipeline || !source || !demuxer || !decvd || !decad || !vdsink || !vdqueue || !adqueue || !adsink) { 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 | ogg-demuxer | vorbis-decoder | converter | alsa-output */ gst_bin_add_many (GST_BIN (pipeline), source, demuxer, decvd, decad, adqueue, vdqueue, vdsink, adsink, NULL); /* we link the elements together */ /* file-source -> ogg-demuxer ~> vorbis-decoder -> converter -> alsa-output */ gst_element_link (source, demuxer); gst_element_link (decvd, vdqueue); gst_element_link (vdqueue, vdsink); //gst_element_link (decad, adqueue); gst_element_link (adqueue, adsink); g_signal_connect (demuxer, "pad-added", G_CALLBACK (on_pad_added), NULL); /* note that the demuxer will be linked to the decoder dynamically. The reason is that Ogg may contain various streams (for example audio and video). The source pad(s) will be created at run time, by the demuxer when it detects the amount and nature of streams. Therefore we connect a callback function which will be executed when the "pad-added" is emitted.*/ /* 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) playvideo.c -o playvideo If everything worked file you will get a "playvideo" arm binary: LTIB> file playvideo playvideo: 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$ ./playvideo your-file-h264-mp3.avi Now playing: your-file-h264-mp3.avi Running...

i.MX Processors Knowledge Base

i.MX Processors Knowledge Base

Discussions

Jumpstart Cloud-Connected Computer Vision and Machine Learning Designs.pdf

create sdcard mirror under windows

A simple way to dump kmsg into mmc storage

Adding RAID & LVM support to Linux BSP for I.MX processors

Guide for building imx8mp isp standalone

Controlling a robotic arm over Wi-Fi with UDOO NEO

Interfacing Depth Sensors on NXP i.MX6 boards

i.MX 6 D/Q/DL/S/SL Linux 3.10.17_1.0.1 Patch Release

Flash customized Linux Kernel Image and device tree using UUU Tool

MX93 USB(2.0) test-mode/output pattern setup in Linux command-line

How to set up camera Dart BCON Basler for iMX8MPlus on Embedded Linux

Alexa SDK support for NXP i.MX Boards

Interfacing Depth Sensors with ROS on NXP i.MX6 boards

i.MX6 VDD_SNVS_CAP Component Recommendation

LAUTERBACH 16bit ETM Adaptor on SABRE AI iMX6 Freescale eval board <EDGE to MICTOR 38>

i.MX 8MQ EVK Display Selection Guide

Full Life Cycle Security Maintenance of Embedded Linux BSPs

Lighting Control Philips Hue Light Through KW20(Zigbee Coordinator) with i.MX6Q

iMX5 system 80 interface LCD driver based on IPUV3

All Boards Creating App Video