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

Hello all. This document shows how to play the puzzle game “2048” on the RIoTboard running Ubuntu. The RIoTboard is an open source platform featuring the powerful i.MX 6Solo, a multimedia application processor with ARM Cortex-A9 core at 1 GHz.For complete information regarding RIoTboard characteristics and its user manual, you could refer to the following links: RIoTboard wepage: http://riotboard.org/ User Manual: http://www.element14.com/community/servlet/JiveServlet/previewBody/65502-102-2-288206/RIOT_Board_User_Manual_v1.1.pdf Flashing the Ubuntu image to RioTboard. First, we need to get the Ubuntu image and Mfg Tool from the following page: http://www.element14.com/community/docs/DOC-68442/l/riotboard-bsp-images-and-tools-download--android-and-linux Once getting the software, it is required to configure the Boot Configuration Select switches (SW1) for Serial Downloader Mode as shown below: After completing the download of the software, it is requiered to configure the switches for booting from eMMC, as shown below: For additional details regarding Boot modes, you could refer to chapter 4 of the RioTboard User Manual. How to connect EVBUSB2SER to RIoT board for debug terminal. By default, the Debug serial port of the RioTboard is routed to the J18 header (labeled as “Debug”), so, if you have a EVBUSB2SER board, you could use it to access to this serial port by USB. In order to avoid damages between boards, please ensure of the following (on the EVBUSB2SER board): Switch SW1 is in the 3.3V position. Jumper J3 (which enables the level-shifter IC) is removed, as it won’t be requiered. Finally, the connections between EVBUSB2SER and RioTboard should be as follows: Pin Number on EVBUSB2SER header P1 Pin Number on RIoTboard header J18 7 (RXD) <-----> 1 (UART2_TXD) 8 (TXD) <-----> 2 (UART2_RXD) 9 (GND) <-----> 3 (GND) The following image shows both board connected as mentioned: How to change the HDMI display resolution using bootargs. With the serial console connected, you could see the boot log, and stop the boot process for enter to U-Boot for changing the HDMI display resolution (enviroment variable “bootargs”). If you want to know the default vales, you could call the following command:    printenv bootargs So, for changing the resolution to 1920x1080 and then booting, you should do the following: setenv bootargs console=ttymxc1,115200 nosmp video=mxcfb0:dev=hdmi,1920x1080M@60,bpp=32 video=mxcfb1:off saveenv boot Getting the source code of 2048 game and compiling it. On the following webpage you could find the source code of a working 2048 game on a single C file: https://github.com/mevdschee/2048.c On the same page are included the instructions for downloading and compiling it, which are the shown below (using either Serial Debug console or a Terminal window). The Ubuntu image should already include the gcc compiler: wget https://raw.githubusercontent.com/mevdschee/2048.c/master/2048.c gcc -o 2048 2048.c If you want to visualize the source code you could try: cat 2048.c Play! Either using Serial Debug console or a Terminal window (or both) you could now launch the 2048 game my simply launching the compiled executable:    ./2048 Below you can find screen captures of the game running on both scenarios: Hope this will be useful and funny for you. Best regards! /Carlos

This documents describes how to add the NFC support to i.MX8M mini evk running Yocto. Hardware setup: The i.MX8M mini evk (see i.MX 8M Mini Evaluation Kit | NXP) featuring Raspberry Pi compliant connector, the OM5578/RPI PN7150 demo kit can be used to perform this porting (see NFC Development Kits for Arduino and more|NXP). However a small modification must be done because some of the signals required by PN7150 are not mapped to i.MX8M mini expansion connector pins. OM5578 IRQ signal must be mapped to Raspberry Pi connector pin #19 and OM5578 IRQ signal must be mapped to Raspberry Pi connector pin #21. See below a picture of the modification: Then, the two boards can fit together as shown in the picture below: Quick start using demo image: The demo image including support for PN7150, is based on i.MX Linux 4.14.78_1.0.0 BSP software release (see i.MX Software | NXP). Related documentation can be downloaded from here: https://www.nxp.com/webapp/Download?colCode=L4.14.78_1.0.0_LINUX_DOCS. Just flash the demo image (downloaded from here: https://www.nxp.com/lgfiles/updates/NFC/LINUX_L4-14-78_IMAGE_MX8MMEVK.zip) following guidelines from i.MX_Linux_User's_Guide document (part of L4.14.78_1.0.0_LINUX Documentation package mentioned above). Then in a terminal you can run the demo application included in the image executing the command:    # nfcDemoApp poll Approaching the NFC tag, provided as reference in the OM5578 demo kit, to the NFC Antenna will trigger such display: Adding PN7150 support to imx-linux-sumo release: Pre-condition is to have L4.14.78_1.0.0 release installed and already built as described in i.MX Yocto Project User's Guide (part of L4.14.78_1.0.0_LINUX Documentation package mentioned above) :     $ repo init -u https://source.codeaurora.org/external/imx/imx-manifest  -b imx-linux-sumo -m imx-4.14.78-1.0.0_ga.xml     $ repo sync     $ MACHINE=imx8mmevk DISTRO=fsl-imx-xwayland source fsl-setup-release.sh -b build_dir     $ bitbake fsl-image-validation-imx Then to add PN7150 support to your imx-linux-sumo environment, follow below step by step guidelines: In the sources directory, download the meta-nxp-nfc layer from https://github.com/NXPNFCLinux/meta-nxp-nfc     $ git clone https://github.com/NXPNFCLinux/meta-nxp-nfc.git  Define hardware connection between CPU and PN7150 in device-tree adding the following lines to file build_dir/tmp/work-shared/imx8mmevk/kernel-source/arch/arm64/boot/dts/freescale/fsl-imx8mm-evk.dts: @@ -227,6 +227,8 @@                         fsl,pins = <                                 MX8MM_IOMUXC_I2C3_SCL_I2C3_SCL                  0x400001c3                                 MX8MM_IOMUXC_I2C3_SDA_I2C3_SDA                  0x400001c3 +                               MX8MM_IOMUXC_ECSPI2_MOSI_GPIO5_IO11             0x41 +                               MX8MM_IOMUXC_ECSPI2_MISO_GPIO5_IO12             0x41                         >;                 };   @@ -747,6 +749,13 @@         pinctrl-0 = <&pinctrl_i2c3>;         status = "okay";   +       pn54x: pn54x@28 { +               compatible ="nxp,pn547"; +               reg = <0x28>; +               interrupt-gpios = <&gpio5 11 0>; +               enable-gpios = <&gpio5 12 0>; +       }; +         pca6416: gpio@20 {                 compatible = "ti,tca6416";                 reg = <0x20>; Add the meta-nxp-nfc layer to the build definition updating file build_dir/conf/bblayers.conf with: BBLAYERS += " ${BSPDIR}/sources/meta-nxp-nfc" Add the meta-nxp-nfc layer components to the image definition updating file build_dir/conf/local.conf with: IMAGE_INSTALL_append = " kernel-module-nxp-pn5xx nxp-nfc-bin " Re-build the linux kernel:     $ bitbake -f -c compile linux-imx && bitbake -f -c deploy linux-imx Build meta-nxp-nfc layer:     $ bitbake nxp-nfc Re-build the complete image to include the modifications:     $ bitbake fsl-image-validation-imx Then you can flash the updated image to your i.MX8M mini evk and run the demo application as described in above "Quick start using demo image" chapter. Reference: This porting have been done (demo image and instructions) following guidelines provided in AN11679_PN71xx_Linux_Software_Stack_Integration_Guidelines document.

This document describes the steps for flashing eMMC from SD Card on i.MX6Q SabreSD board. Download the prebuilt images (Linux 4.1.15) of i.MX6Q SabreSD board from this link. Flash the sdcard image on SD Card. sudo dd if=<sdcard_image> of=/dev/sdX bs=1M && sync Select Boot Mode to SD Card and boot the board from SD Card. Stop the console at u-boot and execute below command. ums 0 mmc 1                 // this will mount SD card as USB Mass Storage to your system Copy bootloader image from system to USB Mass Storage cp <u-boot_image> /media/username/<rootfs>/home/root/ Eject the USB Mass Storage and terminate the ums process by pressing ctrl+c in u-boot. Power Off and Power On the board and login to the kernel console. Flash the bootloader image to eMMC dd if=/home/root/<u-boot_image> of=/dev/mmcblk3 bs=512 seek=2 conv=fsync Mount the partition 1 of SD Card to copy the kernel image and DTB file to /home/root folder. mount /dev/mmcblk2p1 /mnt/ cp -r /mnt/zImage /mnt/imx6q-sabresd.dtb /home/root umount /dev/mmcblk2p1 Make partitions on eMMC manually as per section 4.3.3 in this document using fdisk /dev/mmcblk3 command. Format the partition 1 on eMMC as VFAT and partition 2 as ext4 with below commands mkfs.vfat /dev/mmcblk3p1 mkfs.ext4 /dev/mmcblk3p2 Mount the partion 1 of eMMC and copy kernel image & DTB file. mount /dev/mmcblk3p1 /mnt/ cp -r /home/root/zImage /home/root/imx6q-sabresd.dtb /mnt/ umount /dev/mmcblk3p1 Mount the partion 2 of eMMC & SD Card and copy the file system. mount /dev/mmcblk3p2 /mnt/                                                         // mount partition 2 of SD Card mkdir /home/root/rootfs && mount /dev/mmcblk3p2 rootfs     // mount partition 2 of eMMC cp -ar /mnt/* /home/root/rootfs/ sync umount /dev/mmcblk2p2 umount /dev/mmcblk3p2 Change the Boot Mode to eMMC Power Up the Board. (this will boot the images from eMMC) NOTE: Above steps does not require any other images for eMMC. All the images for eMMC and SD Card are same. Regards, Shivani

Minicom       It's a simple terminal program, easy to configure and use. Can be downloaded and installed from your Linux package distribution (Synaptic, apt-get, yum) or through this link.       Minicom is a terminal emulation that can access a remote serial console enabling the configuration of Bootloader or the flash file system of the board.   Configuring       Run Minicom calling it from Terminal:     $ minicom       Reach the cofiguration by typing CTRL-A Z Press key Z after releasing CTRL and A. Configure Minicom to work with i.MX, follow the procedure below.   Set the Serial Port       At the screen configuration, type O, choosing Configure Minicom In menu, choose Serial Port Setup Below, the configuration option:       +-----------------------------------------------------------------------+ | A - Serial Device  : /dev/ttyS0                            | | B - Lockfile Location  : /var/lock                          | | C - Callin Program  :                                          | | D - Callout Program  :                                        | | E - Bps/Par/Bits  : 115200 8N1                          | | F - Hardware Flow Control : No                          | | G - Software Flow Control : No                            | |                                                                        | | Change which setting?                                      | +-----------------------------------------------------------------------+       Type the letter of option to enable the modification. Remember to choose the right Serial Device. Screen       Another useful program to use with serial ports is screen. It is a screen manager with VT100/ANSI terminal emulation usually available in Linux distributions. To open serial device /dev/ttyS0, for example, using 115200 baudrate, simply use:     $ screen /dev/ttyS0 115200       To kill the screen manager, use Ctrl + a, k. For a list of useful parameters and commands, try:     $ man screen

Introduction There are four boot logos in kk4.4.3_2.0.0-beta  system at first: uboot logo\linux logo\android init logo\android animation. We plan to use uboot logo to cover linux logo and android init logo so that we  can combine first three logoes into one logo.This guide provides a step by step explanation of how to transfer uboot UI to  linux kernel and android init smoothly on board sasbresd_6dq sabresd_6dl. The core ideas of the patch: need to  keep display clock from uboot to kernel. When kernel boot up , we do not break the frambuffer for that it stores uboot logo data. need to disable show android init logo. what do the patch do in uboot 1、 can not shut down video after uboot is over.The patch delete releted code in function  arch_preboot_os() 2、 keep hsp clock (ipu clock) the same with linux 3.10 the below is the setting in sabrasd DQ board: osc(24MHz) -> pll2(528MHz) -> mmdc_ch0(528MHz) -> ipu1_hsp_clk(264MHz) the below is the setting in sabrasd DL board: osc(24MHz) -> pll3(480MHz) -> pll3_pdf1(540MHz) -> ipu1_hsp_clk(270MHz) 3、 keep pixel clock the same with linux 3.10 the below is the setting in sabrasd DQ board: osc(24MHz) -> pll2(528MHz) -> pll2_pfd0(452.57MHz) -> ldb_di1(64.65MHz) -> ipu1_di1(64.65MHz) -> ipu1_pixel(64.65MHz) the below is the setting in sabrasd DL board: osc(24MHz) -> pll2(528MHz) -> pll2_pfd0(452.57MHz) -> ldb_di1(64.65MHz) -> ipu1_di1(64.65MHz) -> ipu1_pixel(64.65MHz) 4、 keep pwm clock In kernel,there is a 100% duty pwm to drive lvds panel.So the patch set the pad SD1_DATA3 to a 100% duty pwm pin. 5、 add fbbase and fbmem to bootargs the fbbase is the uboot logo’s phy addr. So the patch pass the parament to kernel through cmdline.we should allocate address aligned 1M for linux 3.10 reserve address aligned by 1 M. what do the patch do in linux 3.10 1、 reserve the address which come from fbbase 2、 keep  ipu related clock when system init the clock in clk-imx6q.c The patch  enable ldb_di1_clk、ipu1_di1_clk、ipu1_clk、pwm1_clk.  Do not disable pll2 and pll3 related clock for the clock may be the source of  ipu clock. Although we enable ldb_di1_clk、ipu1_di1_clk and so on in register, we need to use the function clk_prepare_enable(). Because  the system may close some clocks for their user count is 0(if we use clk_prepare_enable(),it and it’s parent  user count will add 1 ) 3、 disable cabc which will light the panel according the content. Change cabc_enable in dts file. 4、 Move global alpha and color key setting in probe  after framebuffer is registered. Delay       register IPU interrupts used by framebuffer  until IPU hsp clock is enabled.Because global alpha and color key setting and register IPU interrupts may disable hsp clock. disable show android init logo android init logo is the text"android_". we need disable to show it so that the former three logos looks the same logo.The patch 92-system_core solve this problem. The environment of the patch: Hardware: SABRASD DQ&DL Soft ware: kk4.4.3_2.0.0-beta on linux 3.10 How to use the patch: $ cd my_android/kernel_imx/ $ patch -p1 < ./92-kernel_v2 $ cd my_android/bootable/bootloader/uboot-imx/ $ patch -p1 < ./92-uboot_v2     $ cd my_android/system/core $ patch -p1 < 92-system_core Note:      1、 If you want to have this feature on sabraSD dq&dl board,this patch is OK .After you use this patch, you want to change to  other board such as sx, you may meet this problem that the kernel logo penguin don’t appear. You may change this file: arch/arm/configs/imx_v7_android_defconfig                 CONFIG_LOGO=y                 CONFIG_FRAMEBUFFER_CONSOLE=y                 CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y                 #CONFIG_MX6_CLK_FOR_BOOTUI_TRANS=y                 #CONFIG_MX6_CLK_FOR_BOOTUI_TRANS_LVDS_IPU1_DI1=y

Introduction The Intel® Neural Compute Stick 2 (Intel® NCS 2) is Intel’s newest deep learning inference development kit. Packed in an affordable USB-stick form factor, the Intel® NCS 2 is powered by latest VPU (vision processing unit) – the Intel® Movidius™ Myriad X, which includes an on-chip neural network accelerator called the Neural Compute Engine. With 16 SHAVE cores and a dedicated hardware neural network accelerator, the NCS 2 offers up to 8x performance improvement+ over the previous generation. Ref: https://software.intel.com/en-us/articles/run-intel-openvino-models-on-intel-neural-compute-stick-2   The NCS 2 officially supported hardware platform is x86 PC and Raspberry Pi. In this guide, we will introduce how to implement in i.MX8MQ. Please see attached guide for more details.

The Linux L4.9.11_1.0.0 RFP(GA) for i.MX6 release files are now available on www.nxp.com    Files available: # Name Description 1 L4.9.11_1.0.0-ga_images_MX6QPDLSOLOX.tar.gz 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 2 L4.9.11_1.0.0-ga_images_MX6SLEVK.tar.gz i.MX 6Sololite EVK Linux Binary Demo Files 3 L4.9.11_1.0.0-ga_images_MX6UL7D.tar.gz i.MX 6UltraLite EVK, 7Dual SABRESD, 6ULL EVK Linux Binary Demo Files 4 L4.9.11_1.0.0-ga_images_MX6SLLEVK.tar.gz i.MX 6SLL EVK Linux Binary Demo Files 5 L4.9.11_1.0.0-ga_images_MX7ULPEVK.tar.gz i.MX 7ULP EVK Linux Binary Demo Files  6 L4.9.11_1.0.0-ga_mfg-tools.tar.gz i.MX Manufacturing Toolkit for Linux L4.9.11_1.0.0 BSP 7 L4.9.11_1.0.0-ga_gpu-tools.tar.gz L4.9.11_1.0.0 i.MX VivanteVTK file 8 bcmdhd-1.141.100.6.tar.gz The Broadcom firmware package for i.MX Linux L4.9.11_1.0.0 BSP. 9 imx-aacpcodec-4.2.1.tar.gz Linux AAC Plus Codec for L4.9.11_1.0.0 10 fsl-yocto-L4.9.11_1.0.0.tar.gz L4.9.11_1.0.0 for Linux BSP Documentation. Includes Release Notes, User Guide.   Target boards: i.MX 6QuadPlus SABRE-SD Board and Platform i.MX 6QuadPlus SABRE-AI Board 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 6SoloLite EVK Board i.MX 6SoloX SABRE-SD Board i.MX 6SoloX SABRE-AI Board i.MX 7Dual SABRE-SD Board i.MX 6UltraLite EVK Board i.MX 6ULL EVK Board i.MX 6SLL EVK Board i.MX 7ULP EVK Board (Beta Quality)   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, see: README: https://source.codeaurora.org/external/imx/fsl-arm-yocto-bsp/tree/README?h=imx-morty ChangeLog: https://source.codeaurora.org/external/imx/fsl-arm-yocto-bsp/tree/ChangeLog?h=imx-morty

This is the procedure and patch to set up Ubuntu 12.04 64bit Linux Host PC and building i.MX6x L3.0.35_4.1.0.  It has been tested to build GNOME profile and with FSL Standard MM Codec for i.MX6Q SDB board. A) Basic Requirement: Set up the Linux Host PC using ubuntu-12.04.3-desktop-amd64.iso Make sure the previous LTIB installation and the /opt/freescale have been removed B) Installed the needed packages to the Linux Host PC $ sudo apt-get update $ sudo apt-get install gettext libgtk2.0-dev rpm bison m4 libfreetype6-dev $ sudo apt-get install libdbus-glib-1-dev liborbit2-dev intltool $ sudo apt-get install ccache ncurses-dev zlib1g zlib1g-dev gcc g++ libtool $ sudo apt-get install uuid-dev liblzo2-dev $ sudo apt-get install tcl dpkg $ sudo apt-get install asciidoc texlive-latex-base dblatex xutils-dev $ sudo apt-get install texlive texinfo $ sudo apt-get install ia32-libs libc6-dev-i386 lib32z1 $ sudo apt-get install uboot-mkimage $ sudo apt-get install scrollkeeper $ sudo apt-get install gparted $ sudo apt-get install nfs-common nfs-kernel-server $ sudo apt-get install git-core git-doc git-email git-gui gitk $ sudo apt-get install meld atftpd C) Unpack and install the LTIB source package and assume done on the home directory: $ cd ~ $ tar -zxvf L3.0.35_4.1.0_130816_source.tar.gz $ ./L3.0.35_4.1.0_130816_source/install After that, you will find ~/ltib directory created D) Apply the patch to make L3.0.35_4.1.0 could be installed and compiled on Ubuntu 12.04 64bit OS $ cd ~/ltib $ git apply 0001_make_L3.0.35_4.1.0_compile_on_Ubuntu_12.04_64bit_OS.patch The patch modifies the following files: dist/lfs-5.1/base_libs/base_libs.spec dist/lfs-5.1/ncurses/ncurses.spec E) Then, it is ready to proceed the rest of the LTIB env setup process: $ cd ~/ltib $ ./ltib -m config $ ./ltib Reference: L3.0.35_4.1.0_130816_docs/doc/mx6/Setting_Up_LTIB_host.pdf https://community.freescale.com/message/332385#332385 https://community.freescale.com/thread/271675 https://community.freescale.com/message/360556#360556 scrollkeeper is for the gnome-desktop compilation NOTE: When compiling gstreamer, this warning was pop up.  Just ignore it seems okay.

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.

    On latest iMX8QXP MEK board, the hardware connected the SCU_GPIO0_00 and SCU_GPIO0_01 pins for SCU debug UART, and customer can enable "#define ALT_DEBUG_SCU_UART" from "imx-scfw-porting-kit-1.1/src/scfw_export_mx8qx_b0/platform/board/mx8qx_mek/board.c" to open the SCFW debug UART for early board bring up.     And if customer enabled "#define ALT_DEBUG_UART" from board.c, then SCFW will use ADC_IN2 and ADC_IN3 pins for debug UART.     In this document, it is another choice, SCFW can also use UART0_RX and UART0_TX pins as SCU debug UART for early board bring up. It is based on released "imx-scfw-porting-kit-1.1.tar.gz".     That means on early MEK boards and customer boards which haven't reserved debug UART for SCU, they can also check the SCFW boot log from UART0 port. "scfw-porting-kit-1.1-sc_uart-on-uart0.patch" is the reference patch for such modification. Enable "#define ALT_DEBUG_SCU_UART_ON_UART0" to make it work. Note: since UART0 pins had been used in SCFW, they can't be used in UBoot and linux kernel at the same time, so when debuging UBoot and Linux kernel, you need disable "ALT_DEBUG_SCU_UART_ON_UART0" in SCFW, or you can use other UART port and pins.

This document is a simple guide on one of the ways in which 3D models can be loaded and displayed using OpenGL.   Requirements - Blender (open source) or a similar program that allows to export 3D models in the .obj format. We’ll be using Blender to export the .obj file with the essential information to draw the 3D model, without information on textures, for example. https://www.blender.org/   - i.MX6 Linux BSP image with X11 support – For this document we’ll use the L3.10.31 BSP, which is compiled using Yocto 1.6.You may use a newer BSP. We’ll use the fsl-image-gui. You may use a Qt5 image with X11 from newer BSPs. - GCC Toolchain -You may either cross compile on a Host or compile on the same board by providing the necessary libraries and toolchain. On the L3.10.31 you need to manually add GCC to your baked image. In newer releases this may not necessary. For adding the GCC package to a Yocto image and compiling within the board itself please add the following line to the conf/local.conf file inside your build directory. IMAGE_INSTALL_append += " gcc libgcc" If you wish to cross compile from your host and then run on your board you first will need to extract the toolchain from the BSP, which can be done by following the instructions of the next document: https://community.nxp.com/docs/DOC-95122  - FreeGLUT – FreeGLUT is an open source alternative to the OpenGL Utility Toolkit (GLUT), a window system independent toolkit for writing OpenGL programs. It implements a simple windowing application programming interface (API) for OpenGL. This is not necessary for drawing the model on the window but foes allow for functions such as rotating it. You may install it on your host with the following command: $ sudo apt-get install freeglut3-dev For additional information and downloads of FreeGLUT please refer to the projects website: http://freeglut.sourceforge.net/   - i.MX6D/Q/DL/S/SX GPU Demo Framework SDK – We’ll use the GPU Test examples which are available at the following link. Source code for this document implementation is attached but for more examples of OpenGL ES please refer to this SDK. (Please note that you may need to login in order to download this file) https://www.nxp.com/webapp/Download?colCode=FSL_GPU_SDK_2.3&appType=license&location=null&fpsp=1&WT_TYPE=Software%20Development%20Kits&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=zip&WT_ASSET=Downloads&fileExt=.zip&Parent_nodeId=1337637154535695831062&Parent_pageType=product   - i.MX6Q Board – For this example we will be using the i.MX6Q SABRE Board, but you may run OpenGL ES on any i.MX6Q board provided that you provide the necessary packages to support OpenGL ES.   Brief introduction to OpenGL ES? OpenGL is a software interface to hardware accelerated graphics. The API of this interface consists of about 150 distinct commands that allow you to specify objects and perform operations on them in order to produce interactive three-dimensional applications. OpenGL ES is the OpenGL implementation for Embedded Systems. Somei.MX6 Processors like the i.MX6Q possess a Vivante GPU module that runs on OpenGL ES. When using OpenGL or OpenGL ES all 3D objects are descripted as a series of triangles. This is important to mention as it will make the instructions we will need for describing our model make more sense.   Step 1 - Exporting a model as .obj You may import a 3D model from other sources or make your own simple 3D model in blender. For this example we’ll make a simple 3D NXP logo and export it. Once you have your model ready, select the object in objet mode with a right click. Once selected select File > Export > Wavefront (.obj) You may now select where and with what name to export the object file. On the left panel you will have the export options. It’s important to leave all options unchecked except for: Write Normals Include UVs Triangulate Faces (You may change the scale of your model and it won’t negatively affect the process)     The .obj model may be opened with a text editor and we’ll see that it basically describes the object as a series of parameters that may include vertex data, free-form curve/surface attributes, elements, free-form curve/surface body statements, connectivity between free-form surfaces, grouping and display/render attribute information. For our example we’ll be using a simple file that just contains: - List of geometric vertices, with (x,y,z) coordinates v 0.292475 0.017345 -0.152653 - List of vertex normals in (x,y,z) form vn 0.0000 1.0000 -0.0000 - Polygonal face element f 3//1 113//1 4//1   Step 2- Converting .obj to OpenGL compatible information We’ll be using the following program that allows to convert from .obj format to a format compatible with OpenGL as the conversion from one format to the other is not part of the scope of this document. https://fr.jeffprod.com/obj-to-opengl.php This program does more than just changing the format on the file and do perform some operations to translate the parameters of the .obj file to the following OpenGL ES information: static GLfloat v_triangles[] static GLfloat vt_triangles[] static GLfloat vn_triangles[] We’ll be using these variables and also the number of triangles which for this example is 1440. This can be found at the end of the file on the following line which effectively draws the complete triangle array: glDrawArrays(GL_TRIANGLES, 0, 1440);   Step 3 – Loading the model arrays to the .C program. You will need to copy the three GLfloat arrays to your OpenGL ES .C code. (You may alternatively use an include to have it more neatly organized but this is outside the scope of this document) In our example we’ll copy them inside void render (). Inside this function we’ll find the Draw Array instruction in which we must specify the number of triangles in our array. You may just replace your model information AND also change the number of triangles, otherwise you will receive an error when running the program.   glDrawArrays(GL_TRIANGLES,0,1440); We are using a simple rotation using glRotate and incrementing the value of rotation with each flush of the screen.     glRotatef(rlogo, 2.0f, 1.0f, 1.0f); The variable rlogo gets increased each time the screen is drawn. Depending on your model you may need to change the view in order to be able to see your model. This example uses a very small model so we have a viewpoint just 1.25 units away from the screen (Z axis). Depending on your model you may need to be further away in order to see the model on the screen. glTranslatef(0.0f, 0.0f, -1.25f);    Step 4- Compiling the OpenGL example For this simple example we will be using the examples from the GPU  as base an add the information of the model we have just exported. We’ll use the two attached files for this: Makefile.x11 – A make file with the dependencies and attributes necessary to compile our C file. NXPlogo.c – C file with the information of the model and instructions on to draw it on the screen. You can compile using the following commands to first clean in case you built before and then compiling the code. make –f Makefile.x11 clean make Makefile.x11 Once the program has compiled you can run it from the command prompt by using: export DISPLAY=:0.0 ./NXPlogo The result will be as follows, where the 3D model is rotating,     Additional Resources 2D and 3D Graphics in NXP Devices http://www.nxp.com/files/training/doc/dwf/DWF13_AMF_CON_T1025.pdf   i.MX6D/Q/DL/S/SX GPU Demo Framework SDK – Which provides the source code for the demo in which this example was built upon and also contains good documentation for those interested in OpenGL ES. https://www.nxp.com/webapp/Download?colCode=FSL_GPU_SDK_2.3&appType=license&location=null&fpsp=1&WT_TYPE=Software%20Development%20Kits&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=zip&WT_ASSET=Downloads&fileExt=.zip&Parent_nodeId=1337637154535695831062&Parent_pageType=product    OpenGL Redbook – Which is the most comprehensive book documenting and explaining the OpenGL API. http://www.opengl-redbook.com/

     

   

Hello, here Jorge. On this post I will explain how to configure, record and play audio using an i.MX 8MIC-RPI-MX8 Board. Requirements: I.MX 8M Mini EVK Linux Binary Demo Files - i.MX 8MMini EVK (L5.15.52_2.1.0) i.MX 8MIC-RPI-MX8 Board Serial console emulator (Tera Term, Putty, etc.) Headphones/speakers The 8MIC-RPI-MX8 accessory board is designed for voice enabled application prototyping and development on the i.MX 8M family. The board plugs directly into the 40-pin expansion connector on the i.MX 8M Mini and Nano EVK’s. Some features about this board are: 8 PDM Microphones 8 monochrome LEDs 4 multi-color LEDs 2 status LEDs 4 pushbuttons Microphone Mute Switch Microphone geometry switch Connecting the i.MX 8MIC-RPI-MX8 Board. The i.MX 8MIC-RPI-MX8 Board has a 40-pin expansion connector that you can plug it directly to the EVK board. Ensure that pin 1 of the 8MIC-RPI-MX8 is aligned with pin 1 on the EVK J1001 as is showed on the next figure: Jorge7u7_0-1670005208140.png  Selecting the device tree on the board. Once the pre-compiled image is flashed on the board (Flashing Linux BSP using UUU) and you connected the 8MIC-RPI-MX8 it is necessary to select the correct device tree to handle 8MIC board. On U-boot check the available .dtb files on the BSP using the next command: u-boot=> fatls mmc 2:1 And you will get the corresponding list of .dbt files: Jorge7u7_1-1670005485949.png  On this case we are working with an I.MX 8M Mini EVK and the corresponding .dtb file is: imx8mm-evk-8mic-revE.dtb To select it you need to set the environment variable and save it with: u-boot=> setenv fdtfile imx8mm-evk-8mic-revE.dtb u-boot=> saveenv Doble check it using: u-boot=> printenv fdtfile Jorge7u7_2-1670005606208.png   Now it is time to boot Linux using the next command: u-boot=> boot Recording audio with the i.MX 8MIC-RPI-MX8 Board. The Advanced Linux Sound Architecture (ALSA) provides audio and MIDI functionality to the Linux operating system. ALSA has the following significant features: Efficient support for all types of audio interfaces, from consumer sound cards to professional multichannel audio interfaces. Fully modularized sound drivers. SMP and thread-safe design. User space library (alsa-lib) to simplify application programming and provide higher level functionality. Support for the older Open Sound System (OSS) API, providing binary compatibility for most OSS programs. Once we are on Linux, we can check our audio codecs detected on the board using: arecord -l Jorge7u7_3-1670005796126.png   Now, to record audio we need to use the ALSA arecord command to start recording with IMX8 boards, there are different options that you can check on the next link. On this case we are going to use the next: arecord -D hw:imxaudiomicfil -c8 -f s16_le -r48000 -d10 sample.wav -D: selects the device. -c: selects the number of channels on the recording. -f: selects the format. -r: selects the sample rate. -d: determinate the duration recording time in seconds. sample.wav: Is the name of the resulting audio file. Running the last command, we started to record audio. It is time to make some noise and record it! Jorge7u7_4-1670005841083.png   Playing audio from IMX8 boards. Now it is time to connect our headphones or speakers to the jack. Jorge7u7_5-1670005931730.png   Also, as on arecord command you can check the devices where you can play audio from the board using the next command: aplay -l And you will get all the codecs to play audio: Jorge7u7_6-1670005960006.png   To play our recordings we need to use the ALSA aplay command, it is important to select the correct audio codec to hear the audio from the jack on the board: aplay -Dplughw:3,0 sample.wav -D: selects the device. sample.wav: Is the name of audio file to play Jorge7u7_7-1670006012397.png   Hope this will helpful for people who wants to record audio using PDM microphones and playing audio from IMX8 boards. Best regards.

In FSL i.MX53 reference design, it is configured as: static struct mxc_audio_platform_data sgtl5000_data = { .ssi_num = 1, .src_port = 2, .ext_port = 5, .hp_irq = gpio_to_irq(HEADPHONE_DEC_B), .hp_status = headphone_det_status, .init = mxc_sgtl5000_init, .ext_ram_rx = 1, }; by default. If change the configuration to be : static struct mxc_audio_platform_data sgtl5000_data = { .ssi_num = 0, .src_port = 1, .ext_port = 5, .hp_irq = gpio_to_irq(HEADPHONE_DEC_B), .hp_status = headphone_det_status, .init = mxc_sgtl5000_init, .ext_ram_rx = 1, }; There will prompt "imx_ssi_irq mxc_ssi SISR 8003a3 SIER 180100 fifo_errs=XXXX"  constantly, and audio is greatly distorted. The root cause of this issue is that SSI1/3 use SDMA, and also use IPMUX, but there is not the clock dependency between SDMA and IPMUX, so sometimes IPMUX clock is closed automatically. The attached patch may fix this issue. NOTE: If use SSI2 .ssi_num = 1,             .src_port = 2, If use SSI1 .ssi_num = 0,             .src_port = 1,

  When considering EIM bursts (performance, burst length, etc) we should take into account, that some parameters (maximum burst length, which defines length in clocks of back-to-back EIM access) depend on master, which performs the access (EIM always service as slave). The EIM can split a master burst in order to meet own settings, but the EIM cannot join two master accesses. So, the maximum  burst length is defined by master.  Usually three options are applied for EIM burst accesses : - ARM block copy instructions (LDM / STM) ; - ARM NEON copy instructions (VLDM / VSTM) ; - i.MX SDMA.   Below are some details regarding these options.   1. ARM. ARM provide recommendations below about the fastest way to copy memory on a Cortex-A8. http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka13544.html   According to section 8.1.2 (Supported AXI transfers) of ARM Cortex-A9 Technical Reference Manual, it is possible to get maximum 64 bytes (16 beats x 4 bytes) burst for read and 8 bytes burst for write. “INCR N (N:1-16) 32-bit read transfers INCR N (N:1-2) for 32-bit write transfers” http://infocenter.arm.com/help/topic/com.arm.doc.ddi0388i/DDI0388I_cortex_a9_r4p1_trm.pdf 2. SDMA.   According to section 55.4.3.1 (Burst DMA Unit) of the i.MX6 DQ RM : “Perform up to 8-beat read and write bursts to the ARM platform memory, which optimizes throughput when accessing SDRAM-type devices because of an internal, 36-byte FIFO”. This means, that burst length of the SDMA cannot be greater than 32 bytes (8 beat x 4 bytes). As for performance and implementation of SDMA approach, please look at the following : “Measure SDMA Memory To Memory Copy Performance on i.MX6Q” https://community.freescale.com/docs/DOC-103127

Platform: i.MX8QXP/8QM OS: Linux Supported Camera Modules: Max9286 + Max9271 + OV10635, Default BSP Max9286 + Max96705 + AR0144, patch Max9286 + Max96705 + OV9284, patch Max9286 + Max96705 + AP0101 + AR0132, patch NVP6324 + NVP2431 + IMX225, patch TP2855 + TP3812 + IMX307, patch ISL7998x + NTSC/PAL Sensor, patch adv7180 + NTSC/PAL Sensor, patch Detailed description in the attachment.

    Some customer will use NAND flash as the storage device, also in auto application field,  the fast boot is also necessary,  so how to make the read speed faster is a question. FSL provide some patches for fast boot, they’re also suitable for NAND fast boot. These patch mainly enable the MMU and SDMA in uboot, some part of the patches is special for MMC.        0001-Merge-from-12.0.4-fastboot.patch     0002-Add-fsclmmcdma-code.patch    Some NAND flash support the EDO feature, according to the device feature mode, the NAND flash can be set different clock frequency.  Here will describe how to calculate the NAND working clock.    The NAND clock is divider from the GPMI source clock, can be program in setup_gpmi_nand().  The  divider was configured in register GPMI_TIMING0, the NAND clock can get from the following:           NANDCLK=GPMICLK/(DATA_HOLD+DATA_SETUP)    NAND Clock will affect the speed a lot, for the NAND chipsets which support the EDO, the nand speed will be set automatically. For those doesn’t support EDO NAND chip, the usr should take care those setting manually. There is also a patch for enable EDO mode and set NAND clock automatically.               0008-NAND-configure-as-EDO-mode-5.patch     Besides above, there are two other patches to improve the speed about 30%, 0009-For-nand-page-align-read-include-read-offset-and-siz.patch enabled the cache read(Note: please make sure the NAND chipset support cache read), it will reduce the unnecessary command transfer between the CPU and NAND, 0010-If-possible-directly-use-user-buffer-as-BCH-nand-buf.patch remove some unnecessary memcpy.