Just sharing some experiences during the development and studying.   Although, it appears some hardwares, it focuses on software to speed up your developing on your  hardware.     杂记共享一下在开发和学习过程中的经验。    虽然涉及一些硬件，但其本身关注软件，希望这些能加速您在自己硬件上的开发。 3/4/2025 GPIO USB ID GPIO USB ID - NXP Community   1/20/2025 MDIO on GPIOs MDIO on GPIOs - NXP Community   12/09/2024 GPIO LEDs https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/GPIO-LEDs/ta-p/2009743     10/22/2024 iMX93-EVK PWM LED https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/iMX93-EVK-PWM-LED/ta-p/1978047   07/25/2024 iMX secondary boot collection https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/iMX-secondary-boot-collection/ta-p/1916915   07/25/2024 HSM Code-Signing Journey https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/HSM-Code-Signing-Journey/ta-p/1882244 25JUL2024 - add pkcs11 proxy                         HSM Code-Signing Journey_25JUL2024.pdf                          HSM Code-Signing Journey_25JUL2024.txt   06/06/2024 HSM Code-Signing Journey https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/HSM-Code-Signing-Journey/ta-p/1882244     02/07/2024 Device Tree Standalone Compile under Windows https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/Device-Tree-Standalone-Compile-under-Windows/ta-p/1855271   02/07/2024 i.MX8X security overview and AHAB deep dive i.MX8X security overview and AHAB deep dive - NXP Community   11/23/2023 “Standalone” Compile Device Tree https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/Standalone-Compile-Device-Tree/ta-p/1762373     10/26/2023 Linux Dynamic Debug https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/Linux-Dynamic-Debug/ta-p/1746611   08/10/2023 u-boot environment preset for sdcard mirror u-boot environment preset for sdcard mirror - NXP Community   06/06/2023 all(bootloader, device tree, Linux kernel, rootfs) in spi nor demo imx8qxpc0 mek all(bootloader, device tree, Linux kernel, rootfs)... - NXP Community     09/26/2022 parseIVT - a script to help i.MX6 Code Signing parseIVT - a script to help i.MX6 Code Signing - NXP Community   Provide  run under windows   09/16/2022   create sdcard mirror under windows create sdcard mirror under windows - NXP Community     08/03/2022   i.MX8MM SDCARD Secondary Boot Demo https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8MM-SDCARD-Secondary-Boot-Demo/ta-p/1500011     02/16/2022 mx8_ddr_stress_test without UI   https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/mx8-ddr-stress-test-without-UI/ta-p/1414090   12/23/2021 i.MX8 i.MX8X Board Reset https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8-i-MX8X-Board-Reset/ta-p/1391130       12/21/2021 regulator userspace-consumer https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/regulator-userspace-consumer/ta-p/1389948     11/24/2021 crypto af_alg blackkey demo crypto af_alg blackkey demo - NXP Community   09/28/2021 u-boot runtime modify Linux device tree(dtb) u-boot runtime modify Linux device tree(dtb) - NXP Community     08/17/2021 gpio-poweroff demo https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/gpio-poweroff-demo/ta-p/1324306         08/04/2021 How to use gpio-hog demo https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/How-to-use-gpio-hog-demo/ta-p/1317709       07/14/2021 SWUpdate OTA i.MX8MM EVK / i.MX8QXP MEK https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/SWUpdate-OTA-i-MX8MM-EVK-i-MX8QXP-MEK/ta-p/1307416     04/07/2021 i.MX8QXP eMMC Secondary Boot https://community.nxp.com/t5/i-MX-Community-Articles/i-MX8QXP-eMMC-Secondary-Boot/ba-p/1257704#M45       03/25/2021 sc_misc_board_ioctl to access the M4 partition from A core side sc_misc_board_ioctl to access the M4 partition fr... - NXP Community     03/17/2021 How to Changei.MX8X MEK+Base Board  Linux Debug UART https://community.nxp.com/t5/i-MX-Community-Articles/How-to-Change-i-MX8X-MEK-Base-Board-Linux-Debug-UART/ba-p/1246779#M43     03/16/2021 How to Change i.MX8MM evk Linux Debug UART https://community.nxp.com/t5/i-MX-Community-Articles/How-to-Change-i-MX8MM-evk-Linux-Debug-UART/ba-p/1243938#M40       05/06/2020 Linux fw_printenv fw_setenv to access U-Boot's environment variables Linux fw_printenv fw_setenv to access U-Boot's env... - NXP Community     03/30/2020 i.MX6 DDR calibration/stress for Mass Production https://community.nxp.com/docs/DOC-346065     03/25/2020 parseIVT - a script to help i.MX6 Code Signing https://community.nxp.com/docs/DOC-345998     02/17/2020 Start your machine learning journey from tensorflow playground Start your machine learning journey from tensorflow playground      01/15/2020 How to add  iMX8QXP PAD（GPIO) Wakeup How to add iMX8QXP PAD（GPIO) Wakeup    01/09/2020 Understand iMX8QX Hardware Partitioning By Making M4 Hello world Running Correctly https://community.nxp.com/docs/DOC-345359   09/29/2019 Docker On i.MX6UL With Ubuntu16.04 https://community.nxp.com/docs/DOC-344462   09/25/2019 Docker On i.MX8MM With Ubuntu https://community.nxp.com/docs/DOC-344473 Docker On i.MX8QXP With Ubuntu https://community.nxp.com/docs/DOC-344474     08/28/2019 eMMC5.0 vs eMMC5.1 https://community.nxp.com/docs/DOC-344265     05/24/2019 How to upgrade  Linux Kernel and dtb on eMMC without UUU How to upgrade Linux Kernel and dtb on eMMC without UUU     04/12/2019 eMMC RPMB Enhance and GP https://community.nxp.com/docs/DOC-343116   04/04/2019 How to Dump a GPT SDCard Mirror(Android O SDCard Mirror) https://community.nxp.com/docs/DOC-343079   04/04/2019 i.MX Create Android SDCard Mirror https://community.nxp.com/docs/DOC-343078   04/02/2019: i.MX Linux Binary_Demo Files Tips  https://community.nxp.com/docs/DOC-343075   04/02/2019:       Update Set fast boot        eMMC_RPMB_Enhance_and_GP.pdf   02/28/2019: imx_builder --- standalone build without Yocto https://community.nxp.com/docs/DOC-342702   08/10/2018: i.MX6SX M4 MPU Settings For RPMSG update    Update slide CMA Arrangement Consideration i.MX6SX_M4_MPU_Settings_For_RPMSG_08102018.pdf   07/26/2018 Understand ML With Simplest Code https://community.nxp.com/docs/DOC-341099     04/23/2018:     i.MX8M Standalone Build     i.MX8M Standalone Build.pdf     04/13/2018:      i.MX6SX M4 MPU Settings For RPMSG  update            Add slide CMA Arrangement  Consideration     i.MX6SX_M4_MPU_Settings_For_RPMSG_04132018.pdf   09/05/2017:       Update eMMC RPMB, Enhance  and GP       eMMC_RPMB_Enhance_and_GP.pdf 09/01/2017:       eMMC RPMB, Enhance  and GP       eMMC_RPMB_Enhance_and_GP.pdf 08/30/2017:     Dual LVDS for High Resolution Display(For i.MX6DQ/DLS)     Dual LVDS for High Resolution Display.pdf 08/27/2017:  L3.14.28 Ottbox Porting Notes:         L3.14.28_Ottbox_Porting_Notes-20150805-2.pdf MFGTool Uboot Share With the Normal Run One:        MFGTool_Uboot_share_with_NormalRun_sourceCode.pdf Mass Production with programmer        Mass_Production_with_NAND_programmer.pdf        Mass_Production_with_emmc_programmer.pdf AndroidSDCARDMirrorCreator https://community.nxp.com/docs/DOC-329596 L3.10.53 PianoPI Porting Note        L3.10.53_PianoPI_PortingNote_151102.pdf Audio Codec WM8960 Porting L3.10.53 PianoPI        AudioCodec_WM8960_Porting_L3.10.53_PianoPI_151012.pdf TouchScreen PianoPI Porting Note         TouchScreen_PianoPI_PortingNote_151103.pdf Accessing GPIO From UserSpace        Accessing_GPIO_From_UserSpace.pdf        https://community.nxp.com/docs/DOC-343344 FreeRTOS for i.MX6SX        FreeRTOS for i.MX6SX.pdf i.MX6SX M4 fastup        i.MX6SX M4 fastup.pdf i.MX6 SDCARD Secondary Boot Demo        i.MX6_SDCARD_Secondary_Boot_Demo.pdf i.MX6SX M4 MPU Settings For RPMSG        i.MX6SX_M4_MPU_Settings_For_RPMSG_10082016.pdf Security        Security03172017.pdf    NOT related to i.MX, only a short memo

The init file is a key component of the Android boot sequence. It is a program to initialize the elements of the Android system.  Unlike Linux, Android uses its own initialization program. This Android init program processes 2 files, and it executes the commands it finds in both programs. These programs are: ‘init.rc’ and ‘init<machine name>.rc’ (this machine name is the name of the hardware that Android is running on). What does each program contain?: init.rc provides the generic initialization instructions init<machine name>.rc provides specific initialization instructions init<machine name>.rc is imported by the init.rc program. What is the syntax of these .rc files? The android init language consists of 4 classes of statements: Actions, Commands, Services and Options. Actions and Services declare new sections. All the commands or options belong to the section most recently declared. Actions and Services have to have unique names. If a second Action or Service has the same name of a previous one, it is ignored. Actions Actions are sequences of commands. They have a trigger which is used to determine when the action should occur. Actions take following form. On <trigger> <command> <command> <command>… Services Services are programs which init launches and (optionally) restart when it exists Services take the following form. Service <name> <patchname>  [argument] <option> <option>… Options Options are modifiers to services. These affect how and when init runs a service. Critical This is a device-critical service. If it exits more than four times in four minutes, the device will reboor into recovery mode. Disabled This service will not automatically start with its class. It must be explicitly started by name. Setenv <name> <value> Set the environment variable <name> to <value> in the launched process. User <username> Change to username before executing this service. Currently defaults to root. Group <groupname> [<groupname>] Change to groupname before executing this service. Oneshot Do not restart the service when it exists Class <name> Specify a class name for the service. All services in a named class may be started or stopped together. Onrestart Execute a command when service restarts Triggers Triggers are strings which can be used to match certain kinds of events and used to cause an action to occur. Boot This is the first trigger that will occur when init starts (after /init.conf is loaded) Commands: Exec <path> [<arguments>] Fork and execute a program (<path>). This will block until the program completes execution. Export <name> <value> Set the environment variable <name> equal to <value> in the global environment. Ifup <interface> Bring the network interface <interface> online. Import <filename> Parse and init config file, extending the current configuration. Hostname <name> Set the host name Chdir <directory> Change working directory Chmod <octal-dmoe> <path> Change file access permissions Chwon <owner> <group> <path> Change file owner and group Chroot <directory> Change process root directory Class_start <serviceclass> Start all services of the specified class if they are not already running. Class_stop <serviceclass> Stop all services of the specified class if they are currently running. Domainname <name> Set the domain name Enable <servicename> Turns a disabled service into an enabled one. Insmod <path> Install the module at <path> Mkdir <path> Create a directory at <path> Mount <type><device><dir> Attempt to mount the named device at the directory. Restorecon <path> Restore the file named by <path> to the security context specified in the file_contexts configuration. Setcon <securitycontext> set the current process security context to the specified string. Setenforce 0|1 Set the SELinux system wide enforcing status. 0 = permissive. 1 = enforcing. Setprop <name><value> Set system property <name> to <value> Setrlimit <resource><cur><max> Set the rlimit for a resource Setsebool <name><value> Set SELinux Boolean <name> to <value> Start <service> Start a service Stop <service> Stop a service Symlink <target><path> Create a symbolic link at <path> with the value <target> Trigger <event> Trigger an event. Used to queue an action from another action Wait <path> Poll for the existence of the given file and return when found. Write <path> <string> Open the file at <path> and write a string to it. Examples How to run a script: service my_service /data/test   class main   oneshot Here we are declaring the service named 'my service' with location in /data/test. It belongs to the main class and will start along with any other service that belongs with that class and we declare that the service wont restart when it exits (oneshot). Change file access permissions: chmod 0660   /sys/fs/cgroup/memory/tasks Here we are changing access permissions in path /sys/fs/cgroup/memory/tasks Write a string to a file in a path: write  /sys/fs/cgroup/memory/memory/memory.move_charge_at_immigrate   1 Create a symbolic link: symlink  /system/etc /etc Here we are creating a symbolic link to /system/etc -> /etc Set a specific density of the display: setprop ro.sf.lcd_density 240 Here we are setting a system property of 240 to ro.sf.lcd_density Set your watchdog timer to 30 seconds: service watchdog /sbin/watchdogd 10 20 class core We are petting the watchdog every 10 seconds to get a 20 second margin Change file owner: chown root system /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq The new owner being 'root' from the group 'system'

NFS and TFTP Boot 1  Introduction This document explains the required steps to boot Linux Kernel and mount a NFS on your target. 2 Requirements A functional Yocto environment (Images generated for your target). Your preferred target.  (SABRE-AI, SABRE-SD) 1 Ethernet Cable 1 Micro USB cable USB to Serial converter depending on your target features. 3 Yocto Folders When you develop your Linux kernel and Root File System with Yocto, different folders are created and each folder contains different information. {YOCTO_BUILD_DIR}/tmp/deploy/images/ {TARGET}/  This directory contains the output images, like Kernel, U-Boot and the File System in a tar file. This directory will be used to fetch the kernel and device tree blob file only. {YOCTO_BUILD_DIR}/tmp/sysroot/{TARGET}/  This folder contains all the development files used to generate our Yocto images. Here we can find all the dynamic libraries and headers used for development. This folder is used as parameter for cross-compilation. {YOCTO_BUILD_DIR}/tmp/work/{TARGET}-poky-linux-gnueabi/{IMAGE}/1.0-r0/rootfs This folder contains the uncompressed rootfs of our target. This folder will be used as entry in the host NFS server. 4 IP Address and Network Setup This section covers how to boot Linux that mounts the root file system (RFS) over the network. Remember that in this scenario, the RFS exists on the laptop hard drive, and the kernel that runs on the target board will mount the RFS over Ethernet. This setup is used for developing and debugging Linux applications. It allows for applications to be loaded and run without having to re-boot the kernel each time. First some packages on your host need to be installed: # apt-get install xinetd tftp tftpd isc-dhcp-server nfs-kernel-server portmap For development, it is best to have a static IP setup for the board and Linux environment. This way U-Boot options won’t change between reboots as you get a new IP address as you would using DHCP. 4.1 Linux Host Setup This section describes how to setup a static IP in your Linux host environment. This is not required but will allow the IP address of your virtual host system to remain unchanged. Because u-boot parameters use specific IP addresses, this step is recommended because u-boot parameters may need to be updated in the future to match your virtual IP address if it should ever change. You could take the existing IP address and make it static, but you would lose the Internet connection in your virtual machine. Instead we want to make use of the virtual environment and add a secondary Ethernet port that is tied to your wired Internet connection, while keeping the original Ethernet port which can use the wireless connection on your laptop. In the Linux virtual environment, type sudo ifconfig and note that you should have one Ethernet adapter (eth0). The other item listed (lo) is a virtual port for loopback mode. Shutdown the Linux virtual machine In VMware Player, go to Edit virtual machine settings. And add a Bridged Network Adapter, choosing only the wired Ethernet port. And click on OK.  See below for example: Start up the Linux VM. Open a terminal and type: sudo ifconfig You should have a new entry (eth1). This is the new Ethernet port you created in the virtual machine, and it is bridged to your wired Ethernet port. This is the port we want to make a static IP address. To set eth1 to a static IP, open /etc/nework/interfaces sudo gedit /etc/network/interfaces Add the following to set eth1 to your desired IP address. auto eth1 iface eth1 inet static address 192.168.0.100      <-- Your HOST IP netmask 255.255.255.0 gateway 192.168.0.1 Save the file Restart eth1 sudo ifdown eth1 sudo ifup eth1 4.2 Target Setup We need to setup the network IP address of our target. Power On the board and hit a key to stop the U-Boot from continuing. Set the below parameters: setenv serverip 192.168.0.100 <-- This must be your Host IP address setenv ipaddr 192.168.1.102  <-- This must be your target IP addres setenv ip_dyn no The path where the rootfs is placed in our host has to be indicated in the U-Boot: setenv nfsroot /home/usuario/fsl-release-bsp/buildimx6q/tmp/work/imx6qsabresd-poky-linux-gnueabi/fsl-image-gui/1.0-r0/rootfs setenv image zImage setenv fdt_file uImage-imx6q-sabresd.dtb setenv netargs 'setenv bootargs console=${console},${baudrate} ${smp} root=/dev/nfs ip={ipaddr} nfsroot=${serverip}:${nfsroot},v3,tcp' 4.3 TFTP and NFS Configuration Now configure the Trivial File Transfer Protocol (TFTP) server and Networked File System (NFS) server. This is how U-Boot will download (via TFTP) the Linux kernel, and then the kernel will mount (via NFS) its root file system on the computer hard drive. 4.3.1 TFTP Setup Next setup the TFTP server. The following commands show that we are logged in as root (#). If you are not root ($) then precede each instruction with “sudo”. Edit /etc/xinetd.conf gedit /etc/xinetd.conf Add and save the following lines in the file service tftp { socket_type = dgram protocol = udp wait = yes user = root server = /usr/sbin/in.tftpd server_args = -s {YOCTO_BUILD_DIR}/tmp/deploy/images/ {TARGET}/  disable = no } Notice that {YOCTO_BUILD_DIR}/tmp/deploy/images/ {TARGET}/   has to be written as absolute path. Restart the xinetd service service xinetd restart Test that TFTP is working tftp localhost tftp> get {An Image found in the tftp folder} tftp> quit 4.3.2 NFS Setup Edit the /etc/exports file gedit /etc/exports Add the path where the rootfs is found in your host. {YOCTO_BUILD_DIR}/tmp/work/{TARGET}-poky-linux-gnueabi/{IMAGE}/1.0-r0/rootfs *(rw,no_root_squash)                                                                 NOTE:      {YOCTO_BUILD_DIR}/tmp/work/{TARGET}-poky-linux-gnueabi/{IMAGE}/1.0-r0/rootfs may work most of the times,        but it is recommended to untar the {IMAGE}.bz2 in an exported           folder keeping using sudoand keeping the chmod of each file.     3. Restart the NFS service sudo service portmap stop sudo service nfs-kernel-server stop sudo service portmap start sudo service nfs-kernel-server start 5 Host Final Configuration and Booting Linux over NFS In your host, under the images folder {YOCTO_BUILD_DIR}/tmp/deploy/images/ {TARGET}/ create the below links ln -s zImage_imx_v7_defconfig zImage      2. In U-boot type the below command:                run netboot After a pair of minutes you should get a Linux working system on your target.

Android Power Debug and Optimization Introduction Android Power Management on i.MX Overview How to do power optimization for Android on i.MX How to check high power consumption on i.MX How to debug suspend/resume problems on i.MX Introduction This document describes i.MX Android power issues debug and power consumption optimization. Android Power Management on i.MX Overview What Power Manager introduced by Android • Early Suspend    It is allow drivers like LCD, keypad backlight, touch-screen, gsensor, to be notified when user-space writes to /sys/power/request_state to indicate that the user visible sleep state should change. These drivers will act as like Linux stand suspend() to let these devices entry in suspend for better battery life. •Late Resume    Late resume is matching with early suspend. It will resume the devices suspended during early suspend after the Stand Linux resume finished •Wake Locks     Wake locks are used by applications, services, kernel drivers to request CPU resources. A locked wakelock, depending on its type, prevents the system from entering suspend or other low-power states. It as a core member in android power management architecture from framework to kernel What introduced by i.MX to enhance the power framework BusFreq Support High bus, Low power audio bus and Low bus totally 3 system bus working points. Switching between these 3 bus mode according clock flags automatically. DDR running frequency will change according bus mode changing (highest 528/400MHz and lowest at 24MHz for MX6DQ/DL). CPUFreq The CPU frequency scaling device driver allows the clock speed of the CPUs to be changed on the fly. Once the CPU frequency is changed, the GP voltage will be changed to the voltage value. Enhance the default interactive governor for better performance on SDHC/GPU etc. System Power Profile Service and App (just for MX6DQ/DL) Support 3 profiles currently: Normal mode, Power Saving Mode and Performance Mode to get much better balance between performance and power consumption. Profiles can be customized according customers’ HW /MD design, including: CPU running max freq, trigger temperature, CPU running minimal freq, running cpu LDO bypass mode           i.MX6X has built-in LDO module, but also allows you to use external LDO suppliers. SW will provide the configuration using external LDO or internal LDO. How to do power optimization for Android on i.MX Suspend Mode All devices enter in suspend or low power Config GPIO PADs as High Z or input mode (depending on HW design,FSL provide Ref code) Cut off LDOs which no modules need (depending on HW design, FSL provide Ref code) DDR enter in self-refresh mode (FSL done) Config DDR IO Float pin to reduce the DDR IO consumption (FSL done) ARM core entry stop mode (WFI) (FSL done) All PLLs will cut off, just 32KHZ sleep clock living (FSL done) Notify the PMIC entry in standby to save some power (FSL done) User Idle Mode Optimization on device driver for WiFi, 3G, BT, screen brightness modules, etc., to save some power Let some device/GPIOs entry in suspend mode/low power mode Active power saving profile to reduce some system power loading. GPU 2D/3D auto entry in Stop/Standby mode if no activity needs update. (FSL done) Enable CPUFreq reduce ARM CORE power consumption (FSL done) Busfreq scanning to let system work at lower Freq to save power (FSL done) Audio/Video Playback Mode Optimization on device driver for WiFi, 3G, BT, screen brightness modules, etc., to save some power Let some device/GPIOs entry in suspend mode/low power mode Disable HW 3D acceleration for some Apps such as System UI, Music Player, etc., to save some power when System in IDLE or music playing mode. Enable CPUFreq and SOC WAIT mode, decrease CPU Freq/Voltage to save power for ARM CORE when no there is no task need cpu to handle(FSL done) Busfreq scanning will set bus work at low power audio bus mode to save some power (FSL done for audio case) DDR enter in self-refresh mode (FSL done for audio case) Reduce the screen brightness will save some power (for video case) VPU clock auto-gating to save power on SOC domain (for video case, FSL done) GPU 2D/3D auto-gating to save some power on SOC domain (FSL done) Try VDOA+IPU to bypass GPU in video playback(not comment for Android platform, pure Linux environment using this method, for it has some limitation such as the input/output size limit), this can save some power on DDR domain. How to check high power consumption on i.MX Idle Audio/Video Playback high power consumption Check the CPUFreq and  Bus_freq is enabled           cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor           cat /sys/devices/platform/imx_busfreq.0/enable Check whether the system bus working poing   For MX6Q:           cat /sys/kernel/debug/clock/osc_clk/pll2_528_bus_main_clk/periph_clk/mmdc_ch0_axi_clk/rate   For MX6DL/SL:           cat /sys/kernel/debug/clock/osc_clk/pll2_528_bus_main_clk/pll2_pfd_400M/periph_clk/mmdc_ch0_axi_clk/rate Check CPU Loading and Interrupt(cat /proc/interrupts) Check clock tree carefully to see which clocks arenot gated off  but no any modules need them.            powerdebug –d  -c SUSPEND MODE high power consumption Make sure all device entries are in suspend mode Make sure the system entry in DSM(measure the voltage &current of VDDARM_CAP, VDDSOC_CAP,DDR_1V5, VDD_HIGH…)      Some tips help to locate the problems Add debug message in device drivers which may lead high power consumption Enable PM debug in kernel Catch the waveform from these modules which may impact the high power consumption Remove devices from the board or do H/W rework to exclude some H/W problems How to debug suspend/resume problems on i.MX System could not entry in suspend mode Check below settings has been disabled: GPS has been disabled Don't connect USB cable to the board (adb will hold a wake lock) RIL will hold a wake lock if RIL failed to initialize (logcat -b radio) Setting->Application->Developer options->stay awake (stay awake not set) Check all wake locks which holed by kernel have been released          echo 15 > /sys/module/wakelock/parameters/debug_mask Check all user wake locks have been releaed          echo 15 > /sys/module/userwakelock/parameters/debug_mask System hang when resume or suspend Enable PM debug system to get more info about PM in kernel     make menuconfig  enable the PM debug sys [*] Power Management support                                                           [*]   Power Management Debug Support                                                           [*]     Verbose Power Management debugging Add no_console_suspend to the boot option for kernel         This makes the system print more useful info before entry in suspend Check the PMIC_STBY_REQ signal. Measure the VDDARM_IN Using Trace32 or ICE to locate the problem. Using RAMCONSOLE to dump the kernel log after reboot. Kernel resume back from suspend  but Android not    This is usually because of the wrong key layout file Use tool to get power key scan code        getevent  Correct the Keylayout         system/usr/keylayout/****.kl Correct the scandcode with your power key report value to Match the POWE key

Synchronize your source code Create your local branch Why should I create a local branch? Choose your board Start to build Synchronize your source code Source code you have is one week old now. So, first step is synchronize it. $ repo sync‍‍‍ Create your local branch $ repo start <new branch name> --all‍‍‍ Why should I create a local branch? If you change *any* source code (for choosing another preferred kernel, for example) and want to sync again, or use master instead of dylan, you may be able to rebase or sync your source code, even with changes. Or you found a bug, fixed that, and want to send a patch to community. Example of a system with 2 branches: zeus and new_feature (the asterisk shows the current branch)    $ repo branches * new_feature | in all projects zeus | in all projects‍‍‍ Choose your board The following command display the usage, with a list of all supported machines, all supported community distros and examples of Poky's distro: $ source setup-environment build‍ Usage: MACHINE=<machine> DISTRO=<distro> source setup-environment <build-dir> Usage: source setup-environment <build-dir> <machine> machine name <distro> distro name <build-dir> build directory The first usage is for creating a new build directory. In this case, the script creates the build directory <build-dir>, configures it for the specified <machine> and <distro>, and prepares the calling shell for running bitbake on the build directory. The second usage is for using an existing build directory. In this case, the script prepares the calling shell for running bitbake on the build directory <build-dir>. The build directory configuration is unchanged. Supported machines: apalis-imx6 ccimx6ulsbcexpress ccimx6ulsbcpro cgtqmx6 cm-fx6 colibri-imx6 colibri-imx6ull colibri-imx7 colibri-vf cubox-i imx233-olinuxino-maxi imx233-olinuxino-micro imx233-olinuxino-mini imx233-olinuxino-nano imx6dl-riotboard imx6qdl-variscite-som imx6q-dms-ba16 imx6qsabrelite imx6sl-warp imx6ul-pico imx7d-pico imx7s-warp m28evk m53evk nitrogen6sx nitrogen6x nitrogen6x-lite nitrogen7 nitrogen8m pcm052 tx6q-10x0 tx6q-11x0 tx6s-8034 tx6s-8035 tx6u-8033 tx6u-80x0 tx6u-81x0 ventana wandboard imx23evk imx25pdk imx28evk imx51evk imx53ard imx53qsb imx6qdlsabreauto imx6qdlsabresd imx6slevk imx6sllevk imx6sxsabreauto imx6sxsabresd imx6ulevk imx6ullevk imx7dsabresd imx7ulpevk imx8mmevk imx8mqevk imx8qmmek imx8qxpmek ls1012afrwy ls1012ardb ls1021atwr ls1043ardb ls1046ardb ls1088ardb ls1088ardb-pb ls2080ardb ls2088ardb lx2160ardb mpc8548cds p1020rdb p2020rdb p2041rdb p3041ds p4080ds p5040ds-64b p5040ds t1024rdb-64b t1024rdb t1042d4rdb-64b t1042d4rdb t2080rdb-64b t2080rdb t4240rdb-64b t4240rdb Supported Freescale's distros: fslc-framebuffer fslc-wayland fslc-x11 fslc-xwayland Available Poky's distros: poky-altcfg poky-bleeding poky poky-tiny Examples: - To create a new Yocto build directory: $ MACHINE=imx6qdlsabresd DISTRO=fslc-framebuffer source setup-environment build - To use an existing Yocto build directory: $ source setup-environment build ERROR: You must set MACHINE when creating a new build directory. ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ An example of command line to setup the build environment is (read and answer if you accept EULA or not): MACHINE=imx8mmevk DISTRO=fslc-wayland source setup-environment build‍ (...) Do you accept the EULA you just read? (y/n) y EULA has been accepted. Welcome to Freescale Community BSP The Yocto Project has extensive documentation about OE including a reference manual which can be found at: http://yoctoproject.org/documentation For more information about OpenEmbedded see their website: http://www.openembedded.org/ You can now run 'bitbake <target>' Common targets are: core-image-minimal meta-toolchain meta-toolchain-sdk adt-installer meta-ide-support Your build environment has been configured with: MACHINE=imx8mmevk SDKMACHINE=i686 DISTRO=fslc-wayland EULA= ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Now, you are in new created build directory. Your default build/conf/local.conf file can looks like: MACHINE ??= 'imx8mmevk' DISTRO ?= 'fslc-wayland' PACKAGE_CLASSES ?= 'package_rpm' EXTRA_IMAGE_FEATURES ?= "debug-tweaks" USER_CLASSES ?= "buildstats image-mklibs image-prelink" PATCHRESOLVE = "noop" BB_DISKMON_DIRS ??= "\ STOPTASKS,${TMPDIR},1G,100K \ STOPTASKS,${DL_DIR},1G,100K \ STOPTASKS,${SSTATE_DIR},1G,100K \ STOPTASKS,/tmp,100M,100K \ ABORT,${TMPDIR},100M,1K \ ABORT,${DL_DIR},100M,1K \ ABORT,${SSTATE_DIR},100M,1K \ ABORT,/tmp,10M,1K" PACKAGECONFIG_append_pn-qemu-system-native = " sdl" CONF_VERSION = "1" DL_DIR ?= "${BSPDIR}/downloads/" ACCEPT_FSL_EULA = "1"‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ For the current list of supported board, take a look on FSL Community BSP Release Notes 2.4 (Draft document) documentation Or, see the FSL Community BSP  Release Notes Start to build There are a huge list of images available. Some images includes more packages than others, you can see a list of FSL Community BSP images with description here. The list of supported images from Yocto Project (with description) is here. When an image has more packages included, it takes longer to build. Another way to list all the images you have installed in your metadata is: $ find ../sources -name *image*‍‍   For the goal of this training, any image is good, but a suggestion is presented in next command line: (make sure you are still in build directory) $ cd build $ bitbake core-image-base‍‍‍‍‍‍‍‍ Note (Sept2019): Required disk space for build image is ~31GB Go to Yocto Training - HOME Go to Task #1 - Download the source code Go to Task #3 - The build result

Build the tool chain image. It generates the toolchain that will be installed on your host machine and used to build any source code: $ bitbake meta-toolchain It does take some time to build. Why to create a toolchain? Yocto is not intended to be used to package development. Yocto is a linux distribution creator. It´s intended to be a image builder, a rootfs creator. (please, see more about "what is yocto" here and here) So, yocto itself should not be used to "develop" a new package. Although, Yocto can help creating a environment for development like meta-toolchain or Eclipse ADT. Go HOME Go Task #6 - Customize the image

There are two ways: 1. BitBake. Append the package into the IMAGE_INSTALL variable. But In case you want the package in every image,  add a line to your conf/local.conf file IMAGE_INSTALL_append = " package"           Make sure to include the space BEFORE the package name. You can add other packages, just place spaces in-between. In case you want the package in a particular image, e.g. fsl-image-gui,, add it on meta-fsl-demos/recipes-fsl/images/fsl-image-gui.bb IMAGE_INSTALL += " \     ${SOC_IMAGE_INSTALL} \     cpufrequtils \     nano \     packagegroup-fsl-gstreamer \     packagegroup-fsl-tools-testapps \     packagegroup-fsl-tools-benchmark \     packagegroup-qt-in-use-demos \     qt4-plugin-phonon-backend-gstreamer \     qt4-demos \     qt4-examples \     fsl-gui-extrafiles \     package \     " 2. Hob. Due to its graphical nature, adding more packages to a base image is easier than the bitbake way. Run the hob app under the build folder, select your machine and image, then edit the later (click on the Edit image button) In case the package is not available, you need to create it. As a starting point take a look at this example. In case you consider is good enough to be present on the mainstream repos, send the patch to the meta-freescale mailing list.

Abstract This is a small tutorial about running a simple OpenCL application in an i.MX6Q. It covers a very small introduction to OpenCL, the explanation of the code and how to compile and run it.   Requirements   Any i.MX6Q board. Linux BSP with the gpu-viv-bin-mx6q package (for instructions on how to build the BSP, check the BSP Users Guide)   OpenCL overview   OpenCL allows any program to use the GPGPU features of the GC2000 (General-Purpose Computing on Graphics Processing Units) that means to use the i.MX6Q GPU processing power in any program.   OpenCL uses kernels which are functions that can be executed in the GPU. These functions must be written in a C99 like code. In our current GPU there is no scheduling so each kernel will execute in a FIFO fashion. iMx6Q GPU is OpenCL 1.1 EP conformant. The Code   The example provided here performs a simple addition of arrays in the GPU. The header needed to use openCL is cl.h and is under /usr/include/CL in your BSP rootfs when you install the gpu-viv-bin-mx6q package. The header is typically included like this: #include <CL/cl.h> The libraries needed to link the program are libGAL.so and libOpenCL.so those are under /usr/lib in your BSP rootfs.   For details on the OpenCL API check the khronos page: http://www.khronos.org/opencl/ Our kernel source is as follows: __kernel void VectorAdd(__global int* c, __global int* a,__global int* b) {      // Index of the elements to add      unsigned int n = get_global_id(0);      // Sum the nth element of vectors a and b and store in c      c[n] = a[n] + b[n]; } The kernel is declared with the signature     __kernel void VectorAdd(__global int* c, __global int* a,__global int* b).   This takes vectors a and b as arguments adds them and stores the result in the vector c. It looks like a normal C99 method except for the keywords kernel and global. kernel tells the compiler this function is a kernel, global tells the compiler this attributes are of global address space. get_global_id built-in function   This function will tell us to which index of the vector this kernel corresponds to. And in the last line the vectors are added. Below is the full source code commented. //************************************************************ // Demo OpenCL application to compute a simple vector addition // computation between 2 arrays on the GPU // ************************************************************ #include <stdio.h> #include <stdlib.h> #include <CL/cl.h> // // OpenCL source code const char* OpenCLSource[] = { "__kernel void VectorAdd(__global int* c, __global int* a,__global int* b)", "{", " // Index of the elements to add \n", " unsigned int n = get_global_id(0);", " // Sum the nth element of vectors a and b and store in c \n", " c[n] = a[n] + b[n];", "}" }; // Some interesting data for the vectors int InitialData1[20] = {37,50,54,50,56,0,43,43,74,71,32,36,16,43,56,100,50,25,15,17}; int InitialData2[20] = {35,51,54,58,55,32,36,69,27,39,35,40,16,44,55,14,58,75,18,15}; // Number of elements in the vectors to be added #define SIZE 100 // Main function // ************************************************************ int main(int argc, char **argv) {      // Two integer source vectors in Host memory      int HostVector1[SIZE], HostVector2[SIZE];      //Output Vector      int HostOutputVector[SIZE];      // Initialize with some interesting repeating data      for(int c = 0; c < SIZE; c++)      {           HostVector1[c] = InitialData1[c%20];           HostVector2[c] = InitialData2[c%20];           HostOutputVector[c] = 0;      }      //Get an OpenCL platform      cl_platform_id cpPlatform;      clGetPlatformIDs(1, &cpPlatform, NULL);      // Get a GPU device      cl_device_id cdDevice;      clGetDeviceIDs(cpPlatform, CL_DEVICE_TYPE_GPU, 1, &cdDevice, NULL);      char cBuffer[1024];      clGetDeviceInfo(cdDevice, CL_DEVICE_NAME, sizeof(cBuffer), &cBuffer, NULL);      printf("CL_DEVICE_NAME: %s\n", cBuffer);      clGetDeviceInfo(cdDevice, CL_DRIVER_VERSION, sizeof(cBuffer), &cBuffer, NULL);      printf("CL_DRIVER_VERSION: %s\n\n", cBuffer);      // Create a context to run OpenCL enabled GPU      cl_context GPUContext = clCreateContextFromType(0, CL_DEVICE_TYPE_GPU, NULL, NULL, NULL);      // Create a command-queue on the GPU device      cl_command_queue cqCommandQueue = clCreateCommandQueue(GPUContext, cdDevice, 0, NULL);      // Allocate GPU memory for source vectors AND initialize from CPU memory      cl_mem GPUVector1 = clCreateBuffer(GPUContext, CL_MEM_READ_ONLY |      CL_MEM_COPY_HOST_PTR, sizeof(int) * SIZE, HostVector1, NULL);      cl_mem GPUVector2 = clCreateBuffer(GPUContext, CL_MEM_READ_ONLY |      CL_MEM_COPY_HOST_PTR, sizeof(int) * SIZE, HostVector2, NULL);      // Allocate output memory on GPU      cl_mem GPUOutputVector = clCreateBuffer(GPUContext, CL_MEM_WRITE_ONLY,      sizeof(int) * SIZE, NULL, NULL);      // Create OpenCL program with source code      cl_program OpenCLProgram = clCreateProgramWithSource(GPUContext, 7, OpenCLSource, NULL, NULL);      // Build the program (OpenCL JIT compilation)      clBuildProgram(OpenCLProgram, 0, NULL, NULL, NULL, NULL);      // Create a handle to the compiled OpenCL function (Kernel)      cl_kernel OpenCLVectorAdd = clCreateKernel(OpenCLProgram, "VectorAdd", NULL);      // In the next step we associate the GPU memory with the Kernel arguments      clSetKernelArg(OpenCLVectorAdd, 0, sizeof(cl_mem), (void*)&GPUOutputVector);      clSetKernelArg(OpenCLVectorAdd, 1, sizeof(cl_mem), (void*)&GPUVector1);      clSetKernelArg(OpenCLVectorAdd, 2, sizeof(cl_mem), (void*)&GPUVector2);      // Launch the Kernel on the GPU      // This kernel only uses global data      size_t WorkSize[1] = {SIZE}; // one dimensional Range      clEnqueueNDRangeKernel(cqCommandQueue, OpenCLVectorAdd, 1, NULL,      WorkSize, NULL, 0, NULL, NULL);      // Copy the output in GPU memory back to CPU memory      clEnqueueReadBuffer(cqCommandQueue, GPUOutputVector, CL_TRUE, 0,      SIZE * sizeof(int), HostOutputVector, 0, NULL, NULL);      // Cleanup      clReleaseKernel(OpenCLVectorAdd);      clReleaseProgram(OpenCLProgram);      clReleaseCommandQueue(cqCommandQueue);      clReleaseContext(GPUContext);      clReleaseMemObject(GPUVector1);      clReleaseMemObject(GPUVector2);      clReleaseMemObject(GPUOutputVector);      for( int i =0 ; i < SIZE; i++)           printf("[%d + %d = %d]\n",HostVector1[i], HostVector2[i], HostOutputVector[i]);      return 0; } How to compile in Host   Get to your ltib folder and run $./ltib m shell This way you will be using the cross compiler ltib uses and the default include and lib directories will be the ones in your bsp. Then run LTIB> gcc cl_sample.c -lGAL -lOpenCL -o cl_sample. How to run in the i.MX6Q   Insert the GPU module root@freescale/home/user $ modprobe galcore Copy the compiled CL program and then run root@freescale /home/user$ ./cl_sample References   [1] ttp://www.khronos.org/opencl/ Original Attachment has been moved to: libOpenCL.so.zip Original Attachment has been moved to: libCLC_Android.so.zip Original Attachment has been moved to: libOpenCL_Android.so.zip Original Attachment has been moved to: libCLC.so.zip

You already know. Your source code is one week old now, so please, update it (or should I say 'sync' it?)! Get used to update your BSP layers. Recipe Is the name of file that determinates how a package should act. For example, the version, where it is the mainstream repo, how to build, install, link. etc. Kernel For meta-fsl-arm the kernel recipes are under meta-fsl-arm/recipes-kernel/linux (take a look here meta-fsl-arm - Layer containing Freescale ARM hardware support metadata) For meta-fsl-arm, there are 3 kernel recipes: linux-fslc_3.8.bb  --> kernel mainline (from kernel.org) linux-imx_2.6.35.3.bb  --> kernel from FSL, for imx5x and imx28 linux-imx_3.0.35.bb --> kernel from FSL for imx6 Take the linux-imx for imx6 as an example meta-fsl-arm - Layer containing Freescale ARM hardware support metadata The recipe determinates: what´s the compatible machine for this linux version (mx6) what´s the commit ID for the head of this code (SRCREV) (MX6DL and MX6SL have different source code) what´s the patches for the mx6 boards (SRC_URI). In order to see where the source code is cloned from, you need to go to .inc file meta-fsl-arm - Layer containing Freescale ARM hardware support metadata SRC_URI = "git://git.freescale.com/imx/linux-2.6-imx.git \            file://defconfig \ " it´s from git.freescale.com. In addition, there is a defconfig file added on SRC_URI. There is a defconfig file for every board, on every Linux revision. Some defconfigs are shared for more than one board (for example, every mx6 board), and some Linux version are not compatible for some boards (for example, imx53 is only compatible with 2.6.35). During a bitbake linux-imx, a temp folder will be created under build/tmp/armv7-imx6....../linux-imx, with code from git, patches and defconfig. Then bitbake takes that defconfig and configure the kernel, built it, and deploy it. So, in order to change the kernel configuration (make menuconfig) you must replace your defconfig file from meta-fsl-arm/recipes-kernel/linux/linux-imx-3.0.35/mx6 How to change kernel configuration Create the new defconfig Copy it to meta-fsl-arm/recipes-kernel/linux/linux-imx-3.0.35/mx6 (or the right folder for your board/kernel) $ bitbake -c cleansstate linux-imx $ bitbake linux-imx (if you want only the kernel image) $ bitbake fsl-image-gui (if you want to generate a complete image using the new kernel) How to make menuconfig with yocto $ bitbake -c menuconfig linux-imx will generate a config file on tmp/work/imx6qsabresd-poky-linux-gnueabi/linux-imx/3.0.35-r33.10/git/.config The complete step by step to change the kernel configuration $ bitbake -c menuconfig linux-imx (change anything) $ cp tmp/work/imx6qsabresd-poky-linux-gnueabi/linux-imx/3.0.35-r33.10/git/.config ../sources/meta-fsl-arm/recipes-kernel/linux/linux-imx-3.0.35/mx6/defconfig $ bitbake -c cleansstate linux-imx $ bitbake fsl-image-gui The uImage will be under tmp/deploy/image In order to replace only uImage binary into one ready sdcard: $sudo cp tmp/deploy/image/uImage-imx6-XXX.bin /media/user/Boot imx6/uImage Kernel Mainline - kernel.org In order to use kernel mainline instead of linux-imx. Please add the following code to your conf/local.conf PREFERRED_PROVIDER_virtual/kernel = "linux-fslc" Make sure the desired board is supported by kernel.org. In order to take and build kernel mainline manually, please see https://community.freescale.com/docs/DOC-95017 Final points It´s not a simple task, I know. Yocto is not the best tool for use to develop and customize kernel during development stage. It is easier to use an external toolchain (bitbake meta-toolchain). Once the kernel development, or customization, is done, the changes can be integrated in the Yocto so it is managed for production use. I like to have a copy of kernel source code cloned on my machine directly from git.freescale.com, then I can re-configure it, rebuild it, apply some patches, make changes, and build it manually - any way I want it. So, I only change kernel using yocto when I know the bug and I know how to fix it, and I have the patch. (and this is the way I like to work) Although this is how to configure (and even patch) kernel (if you want to patch kernel, follow the example in the recipes) If you face any error, please, let me know. I tested the steps and it worked, but I´m using an Ubuntu machine, not a virtual machine (and I´m not sure how -c menuconfig will act in a virtual machine). Go to Yocto Training - HOME Go to Task #4 - Deploy and test

Understanding and using the .sdcard format One very useful feature enabled by default in both the Yocto Communiy BSP and Release BSP is the option of generating the baked images in .sdcard format. If the .sdcard format is not selected by default it can be enabled on the conf/local.conf file by adding it with the IMAGE_FSTYPES as follow: IMAGE_FSTYPES="sdcard" It’s important to note that if this variable is specified only the file systems typed defined will be created. The default value used most often for this variable is: IMAGE_FSTYPES="tar.bz2 ext3 sdcard" The .sdcard format creates an image with all necessary partitions and loads the bootloader, kernel and rootfs to this image. You can just low level copy the data on this file to the SD card device using dd as on the following command example: $ sudo dd if=<image name>.sdcard of=/dev/sd<partition> bs=1M && sync Partitions used on the .sdcard file The .sdcard partitions looks as follow: IMAGE_ROOTFS_ALIGNMENT Unpartitioned space reserved for the bootloader BOOT_SPACE Kernerl and other data ROOTFS_SIZE The rootfs. Granting more free space on the RootFS partition The size of the .sdcard file will depend solely on the size of the rootfs. This means that the resulting file won’t partition all our SD Card capacity unless we add extra space to the rootfs partition. (Of course there is always the option of editing the partitions once loaded on the SD Card) In order to add more space you may use the IMAGE_ROOTFS_EXTRA_SPACE variable. You may add it to your local.conf file with the added free disk space in Kbytes. For example, if you would like to guarantee 1GB of extra space you may add the following line to your local.conf file. IMAGE_ROOTFS_EXTRA_SPACE = "1048576" It is important to note that this is space additional to the IMAGE_OVERHEAD_FACTOR variable which defines a multiplier that is applied to the initial image size. This is only applied when the multiplier times the By default, the build process uses a multiplier of 1.3 for this variable. This default value results in 30% free disk space added to the image when this method is used to determine the final generated image size. This would mean that there should be 30% of free disk space before post install scripts. If you wish for more space you may edit this variable as bellow: IMAGE_OVERHEAD_FACTOR = "1.5" Which would result in 50% free disk space added to the image, before post install scripts and without considering overhead that may come from the package management system. How the IMAGE_ROOTFS_SIZE is calculated This variable is also measured in Kbytes and it’s determined by the OpenEmbedded build system using an algorithm that considers the initial disk space used for the generated image, the requested size for the image (trough the overhead factor) and the additional free space to be added to the image (trough the extra space variable). The build system first runs a du (disk usage) command to determine the size of the rootfs directory tree. If the IMAGE_ROOTFS_SIZE current value is larger than the disk usage times the overhead factor only the extra space is added. If the IMAGE_ROOTFS_SIZE is smaller than the disk usage times the overhead factor then the disk usage is multiplied times the overhead factor prior to adding the extra space. IMAGE_ROOTFS_SIZE must be set on a default value which is usually very low as it’s just initialized and updated with the actual size requirements each time an image is baked. You may also use this variable directly in order to select the space you would like to allocate to the RootFS.For example setting the RootFS to 2GB would require the following addition to the local.conf file: IMAGE_ROOTFS_SIZE = “2097152” IMAGE_OVERHEAD_FACTOR = “1.0” In this example we would leave the overhead factor to 1 so no extra space is added since we’re specifying the rootfs size that we want.

In our reference design board the eMMC IC is Sandisk SDIN5C2-8 (4.41), and in i.MX6 Reference manual and datasheet we can known that it compatible with the MMC System Specification version 4.2/4.3/4.4, and details in datasheet declare that the uSDHC module is "fully compliant with the MMC command/response sets and Physical Layer as defined in the Multimedia Card System Specification, v4.2/4.3/4.4/4.41, including high-capacity (> 2 GB) HC MMC cards." EMMC4.4/4.41 of cause can work in our released BSP. But eMMC 4.4 has been discontinued and there is a possibility eMMC 4.41 will be discontinued.  And many of our customers will choose the eMMC 4.5 or high verison EMMC 5.0 and EMMC 5.1. And how to make the eMMC 4.5 , EMMC 5.0 and EMMC 5.1 work on i.MX6 ? The EMMC 4.5 or EMMC 5.0 /5.1 is backward-compatible with eMMC4.4, we can use it in eMMC4.4 mode to enable eMMC4.4 functionality and performance on the i.MX6 platform. Booting from a eMMC 4.5 device or high version is not supported,  boot ROM will fall back to the eMMC4.4 standard when a eMMC4.5 or high version capable device is detected. In BSP it is possible to bypass eMMC version checking, so that eMMC v4.5 or high version can work as eMMC v4.4 cards, no specific v4.5 feature supported. Only basic read/write operations are supported. In the source code we can change check value of card->ext_csd.rev. Take the eMMC 4.5 work as example, the current i.MX6 Linux BSP (L3.0.35_4.1.0) has added code to interface with an eMMC4.5 card to operate as an eMMC4.4 card. Change the value of card->ext_csd.rev 5 to 6, now eMMC 5.0 can work as an eMMC 4.4. The code drivers/mmc/core/mmc.c: And for the EMMC 5.0 and EMMC5.1, modify the kernel to support eMMC 5.0 and 5.1 extended CSD revisions, as shown below: /drivers/mmc/core/mmc.c : if (card->ext_csd.rev > 6) {              // The '6' has to be replaced with '7' For EMMC5.0                                                         //  The '6' has to be replaced with '8'  For EMMC5.1 pr_err("%s: unrecognised EXT_CSD revision %d\n", mmc_hostname(card->host), card->ext_csd.rev); err = -EINVAL; goto out;          } After modifying the code we need to rebuild the the firmware uImage used for MfgTool . Update the uImage in Mfgtool , and it can flash successful. Then the eMMC version 5.0 and 5.1 can be used with IMX6 based boards.

Here are my experiences for compiling Qt5.3.0-beta1 on Yocto. Special thanks to Martin Jansa, the maintainer of the meta-qt5 layer and his help on this. My original procedure was based on this tutorial: Building Qt5 using yocto on Wandboard - Wandboard Wiki Reason: Qt5.3 contains a nice new plugin that allows the use of gstreamer output for textures without the CPU intensive step of copying them (Gerrit Code Review). This allows to play even full HD videos and apply all the power of Qt5 (e.g. shaders) to them. Steps: Setup your repo: repo init -u https://github.com/Freescale/fsl-community-bsp-platform -b master-next; repo sync Download meta-qt5 branch: cd sources; git clone -b jansa/qt5-5.3.0-beta1 https://github.com/meta-qt5/meta-qt5.git Checkout a specific revision: cd meta-qt5; git checkout 92be18a3a14deed9d38b8fc6e89f09ba4d730597 Apply the following patch (maybe later no longer needed): diff --git a/recipes-qt/qt5/qt5.inc b/recipes-qt/qt5/qt5.inc index dfc1c76..a2f9a73 100644 --- a/recipes-qt/qt5/qt5.inc +++ b/recipes-qt/qt5/qt5.inc @@ -54,6 +54,7 @@ FILES_${PN}-tools-dbg = " \ " FILES_${PN}-plugins-dbg = " \      ${OE_QMAKE_PATH_PLUGINS}/*/.debug/* \ +    ${OE_QMAKE_PATH_PLUGINS}/*/*/.debug/* \ " # extra packages @@ -98,6 +99,7 @@ FILES_${PN}-tools = " \ " FILES_${PN}-plugins = " \      ${OE_QMAKE_PATH_PLUGINS}/*/*${SOLIBSDEV} \ +    ${OE_QMAKE_PATH_PLUGINS}/*/*/*${SOLIBSDEV} \ " FILES_${PN}-mkspecs = "\      ${OE_QMAKE_PATH_ARCHDATA}/mkspecs \ Define your machine: export MACHINE=xxx (replace with your board) Setup build environment: cd .. ; . setup-environment build edit your local layer conf ("conf/bblayers.conf") and add the following two lines:   ${BSPDIR}/sources/meta-openembedded/meta-ruby \   ${BSPDIR}/sources/meta-qt5 \ edit your local.conf and add the following lines: DISTRO_FEATURES_remove = "x11 wayland" IMAGE_INSTALL_append = " \     firmware-imx-vpu-imx6q \     firmware-imx-vpu-imx6d \ " IMAGE_INSTALL_append = " \     cpufrequtils \     nano \     packagegroup-fsl-gstreamer \     packagegroup-fsl-tools-testapps \     packagegroup-fsl-tools-benchmark \     gstreamer \     gst-plugins-base-app \     gst-plugins-base \     gst-plugins-good \     gst-plugins-good-rtsp \     gst-plugins-good-udp \     gst-plugins-good-rtpmanager \     gst-plugins-good-rtp \     gst-plugins-good-video4linux2 \     qtbase-fonts \     qtbase-plugins \     qtbase-tools \     qtbase-examples \     qtdeclarative \     qtdeclarative-plugins \     qtdeclarative-tools \     qtdeclarative-examples \     qtdeclarative-qmlplugins \     qtmultimedia \     qtmultimedia-plugins \     qtmultimedia-examples \     qtmultimedia-qmlplugins \     qtsvg \     qtsvg-plugins \     qtsensors \     qtimageformats-plugins \     qtsystems \     qtsystems-tools \     qtsystems-examples \     qtsystems-qmlplugins \     qtscript \     qt3d \     qt3d-examples \     qt3d-qmlplugins \     qt3d-tools \     qtwebkit \     qtwebkit-examples-examples \     qtwebkit-qmlplugins \     cinematicexperience \     " PACKAGECONFIG_append_pn-qtmultimedia = " gstreamer010" QT5_VERSION = "5.2.1+5.3.0-beta1+git%" PREFERRED_VERSION_qtbase-native = "${QT5_VERSION}" PREFERRED_VERSION_qtbase = "${QT5_VERSION}" PREFERRED_VERSION_qtdeclarative = "${QT5_VERSION}" PREFERRED_VERSION_qtjsbackend = "${QT5_VERSION}" PREFERRED_VERSION_qtjsbackend-native = "${QT5_VERSION}" PREFERRED_VERSION_qtgraphicaleffects = "${QT5_VERSION}" PREFERRED_VERSION_qtimageformats = "${QT5_VERSION}" PREFERRED_VERSION_qtmultimedia = "${QT5_VERSION}" PREFERRED_VERSION_qtquick1 = "${QT5_VERSION}" PREFERRED_VERSION_qtquickcontrols = "${QT5_VERSION}" PREFERRED_VERSION_qtsensors = "${QT5_VERSION}" PREFERRED_VERSION_qtserialport = "${QT5_VERSION}" PREFERRED_VERSION_qtscript = "${QT5_VERSION}" PREFERRED_VERSION_qtsvg = "${QT5_VERSION}" PREFERRED_VERSION_qttools-native = "${QT5_VERSION}" PREFERRED_VERSION_qtwebkit = "${QT5_VERSION}" PREFERRED_VERSION_qtwebkit-examples = "${QT5_VERSION}" PREFERRED_VERSION_qtxmlpatterns = "${QT5_VERSION}" build an image: bitbake core-image-minimal This image will build QT5.3 for framebuffer. If you want to use it with X11, then adapt according to this tutorial: Integrate Qt5 into yocto sato image on Wandboard - Wandboard Wiki Please tell me, if I missed something. I wrote this as I remembered the steps.

Important: If you have any questions or would like to report any issues with the DDR tools or supporting documents please create a support ticket in the i.MX community. Please note that any private messages or direct emails are not monitored and will not receive a response.   This is a detailed programming aid for the registers associated with i.MX 8/8X DDR initialization.  For more details, refer to the i.MX 8/8X main DDR tools page: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX-8-8X-Family-DDR-Tools-Release/ta-p/1121519   To reduce the number of attachments, older RPAs may be found in the attached zip file. Note: Devices with 17-row addresses (R0-R16) are not supported by this SoC.  ***IMPORTANT: For SCFWv1.7.0 and later, you must use the following RPA versions or later: MX8QXP_C0_B0_LPDDR4_RPA_1.2GHz_v16 MX8DualX_C0_B0_LPDDR4_RPA_1.2GHz_v16 MX8QuadXPlus_DualXPlus_C0_B0_DDR3L_RPA_v22 MX8DualX_C0_B0_DDR3L_RPA_v20 Older versions of the RPA are not aligned to SCFWv1.7.0 and later.  If trying to use an older version of an RPA with SCFWv1.7.0, it will cause the SCFW not to boot.  The offending lines in the DCD output are as follows: For MX8QXP/DualX: DATA 4 0xff190000 0x00000CC8 /* DRC0 bringup */ If the user wishes to use an older RPA with SCFW 1.7.0 and later (not recommended), then the above lines must be removed from older RPA DCD file outputs.  In addition, wrapping these lines are "#ifndef SCFW_DCD", "#else", and "#endif" preprocessor commands.  These should be removed as well.  For example of MX8QXP: [remove] #ifndef SCFW_DCD [remove] -/* For 1200MHz DDR, DRC 600MHz operation */ [remove] DATA 4 0xff190000 0x00000CC8 /* DRC0 bringup */ [remove] #else <keep code as is> [remove] #endif

Update The source code is one week old now, so please, update it! $ repo sync Images - the result of a bitbake Example of a content after bitbake build_mx6/tmp/deploy/images: fsl-image-gui-imx6qsabresd-20130505174618.rootfs.ext3 fsl-image-gui-imx6qsabresd-20130505174618.rootfs.sdcard fsl-image-gui-imx6qsabresd-20130505174618.rootfs.tar.bz2 fsl-image-gui-imx6qsabresd-20130508162511.rootfs.ext3 fsl-image-gui-imx6qsabresd-20130508162511.rootfs.sdcard fsl-image-gui-imx6qsabresd-20130508162511.rootfs.tar.bz2 fsl-image-gui-imx6qsabresd.ext3 fsl-image-gui-imx6qsabresd.sdcard fsl-image-gui-imx6qsabresd.tar.bz2 modules-3.0.35-1.1.0+yocto+g0596856-r32.10-imx6qsabresd.tgz README_-_DO_NOT_DELETE_FILES_IN_THIS_DIRECTORY.txt u-boot.imx u-boot-imx6qsabresd.imx u-boot-imx6qsabresd-v2013.04-r3.imx* uImage uImage-3.0.35-r32.10-imx6qsabresd-20130505174618.bin uImage-imx6qsabresd.bin Get used with generated images. Understand which file is a symbolic link and which one is the image in fact. Symbolic link will always point to latest image. sdcard image Take a look how sdcard is generated here meta-fsl-arm - Layer containing Freescale ARM hardware support metadata The disk layout used is: 0-> IMAGE_ROOTFS_ALIGNMENT    reserved to bootloader (not partitioned) IMAGE_ROOTFS_ALIGNMENT -> BOOT_SPACE    kernel and other data BOOT_SPACE -> SDIMG_SIZE     rootfs Use IMAGE_OVERHEAD_FACTOR to add more space Please, go to original file in order to understand the disk layout. It´s basically some initial space for u-boot. One partition for uImage. One partition for rootfs. The total sdcard size will be calculate for every image, if you want to add more empty space inside generated sdcard, use IMAGE_OVERHEAD_FACTOR. Deploy Deploy the sdcard image: $ sudo dd if=fsl-image-gui-imx6qsabresd.sdcard of=/dev/sdX bs=1M Or, deploy the ext3 rootfs $ sudo dd if=fsl-image-gui-imx6qsabresd.ext3 of=/dev/sdX2 bs=1M Or deploy only the tar.bz rootfs $ sudo mount /dev/sdX2 /mnt/card $ sudo tar xf imagename-imx53qsb.tar.bz2 -C /mnt/card In order to deploy only kernel $ sudo cp uImage-3.0.35-r32.10-imx6qsabresd-20130505174618.bin /media/Boot In order to  deploy only u-boot $ sudo dd if=u-boot-imx6qsabresd-v2012.10-r3.imx of=/dev/sdX bs=512 seek=2 If using HDMI please, modify u-boot environment arguments: setenv mmcargs "setenv bootargs console=${console},${baudrate} root=${mmcroot} rootwait rw video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24" This is the how sdcards are made by meta-fsl-arm. Of course you can use your own. But double check the u-boot bootenv. Plug your sdcard and let the board boot To login: root Go to HOME Go to Task #3 - The build result Go to Task#5 - kernel

Question: What exactly does the DTE/DCE interface in the i.MX6's UART module do and how are RTS and CTS affected by the UARTxUFCR[DTEDCE] bit? In i.MX6 RM, revision 1: Sections 64.2.1.2.1  (CTS) and 64.2.1.2.2 (RTS) both state that CTS and RTS change direction between DCE and DTE modes.  However, sections 64.4.3.1 (RTS_B) and 64.4.3.8 (CTS_B) state they do not change functions.  Is this a documentation error, or is there a difference between CTS/RTS and CTS_B/RTS_B? It appears that some of this is covered in the IOMUX daisy chain by switching which pins are connected to CTS and RTS. Answer: Example 1: UART1 in DTE mode. RTS is an output from the UART IP block so it must be routed to a CTS pin. Therefore, the SELECT_INPUT register could only use settings 00 or 10. Example 2: UART1 in DCE mode. RTS is an input to the UART IP block so it must be routed to an RTS pin. Therefore, the SELECT_INPUT register could only be set to 01 or 11. At this point, we have assumed that the internal signals connected to the UART block do not change direction.  We believe that DCEDTE from the UART block connects into the IOMUX logic and controls the direction of the PAD.  Then, the IOMUX INPUT_SELECT mux is used to choose one of four pads to connect to the UART inputs while the IMOUX MUX_CTRL connects the output path.  Further, we assume it is an error to connect the UART input to a pad configured as an output or a UART output to a pad configured as an input. The attached shows our assumptions For the Uart IP, the CTS_B is always an output and RTS_B always an input. But the RTS_B &CTS_B IO will be swapped  when UART operates in different DTE or DCE mode.  IO port DTE mode DCE mode direction Uart IP port(internal) direction Uart IP port(internal) UART_CTS_B O CTS_B I RTS_B UART_RTS_B I RTS_B O CTS_B UART_TXD O TXD I RXD UART_RXD I RXD O TXD Regarding how to configure the IOMUX, please see the attached PDF.

For long I looked for a working tutorial to build Qt5 with YOCTO (Yocto Training - HOME) both the libraries for the board image and also a toolchain to build Qt5 applications for the board. See the full tutorial here: Building Qt5 using yocto on Wandboard - Wandboard Wiki The Tutorial is written for the Wandboard that also uses an i.MX6 CPU but you can adapt the tutorial for most of the boards of the i.MX6 family I think - in my case it worked with the i.MX6 SABRE AI without problems. You only have to adjust the sysroot and maybe also the toolchain-path because the wiki entry is a little bit older Ask your questions for this topic - maybe I can help.

1. Enable QtMultimedia 1) In “source/meta-qt5/recipes-qt/qt5/qtmultimedia_git.bb”, add “gstreamer” at the end of “PACKAGECONFIG ??=” .      For example on  L3.14.52  bsp, build  x11  backend: PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'alsa', 'alsa', '', d)} \                    ${@bb.utils.contains('DISTRO_FEATURES', 'pulseaudio', 'pulseaudio', '', d)} \                    gstreamer" 2) Build qtmultimedia:  bitbake qtmultimedia 3) Copy the built package to target file system.      For example : cp  -a ./build-x11/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/qtmultimedia/5.5.0+gitAUTOINC+46a83d5b86-r0/image/usr/   /usr   export  DISPLAY=:0 Video example application located at : /usr/share/qt5/examples/multimedia/video/qmlvideo 2. Enable Qt Logging Info export  QT_LOGGING_RULES=<category>[.type]=ture|false      For example: Turn on all debug logging:      export QT_LOGGING_RULES=*.debug=true Turn on all logging level of all multimedia module:      export QT_LOGGING_RULES=qt.multimedia.*=true 3. Performance Checking Gstreamer: overlaysink fps=51.585      gst-launch-1.0 playbin uri=file:///H264_AVC_1080p_30fps_27Mbps_mp3.avi  video-sink=”overlaysink sync=false” Gstreamer: glimagesink fps=43.850      gst-launch-1.0 playbin uri=file:///H264_AVC_1080p_30fps_27Mbps_mp3.avi video-sink="glimagesink sync=false" Qtmultimedia: fps=45.201      ./qmlvideo  -url file:///H264_AVC_1080p_30fps_27Mbps_mp3.avi -hide-perf Current qt5 multimedia has a special video node for imx6 at     "/src/plugins/videonode/imx6" which uses GPU DirectVIV to accelerate the video rendering. So  the rendering performance is almost same as the glimagesink. For check the free run frame rate, the qt multimedia source need change a little bit to set sink sync as false and calculate the real video rendering rate. Set sync as false: In "/src/plugins/gstreamer/mediaplayer/qgstreamerplayersession.cpp" QGstreamerPlayerSession::playbinNotifySource(): -       g_object_set(G_OBJECT(self->m_videoSink), "sync", !self->m_isLiveSource, NULL); +       g_object_set(G_OBJECT(self->m_videoSink), "sync", false/!self->m_isLiveSource/, NULL); Get fps: In "/src/gsttools/qgstvideorenderersink.cpp" +#include <QTime> +gint g_frame_showed; +QTime g_time; + bool QVideoSurfaceGstDelegate::start(GstCaps *caps) … +   g_frame_showed = 0; +   g_time.restart(); … void QVideoSurfaceGstDelegate::stop() … +   printf(">>>>> fps=%f:\n", (gdouble)g_frame_showed*1000/g_time.elapsed()); … bool  QVideoSurfaceGstDelegate::handleEvent(QMutexLocker *locker) …             const bool rendered = m_activeRenderer->present(m_surface, buffer); +   g_frame_showed++; … Or use the attached patch: qtmultimedia_fps_check.diff 4. Streaming Playing:  HTTP RTP RTSP HTTP: ./qmlvideo -url http://10.192.225.205/streaming/http/H264_HP13_1280x720_29_2850_AAC_LC_44_64_NobodyMTV.mp4 RTSP: ./qmlvideo -url rtsp://10.192.225.205/MPEG4_SP1_720x576_30fps_282_AMRNB_TVC.mp4 RTP: QT mediaplayer use gstreamer playbin as the backend, playbin don’t support rtp address as uri. So QT mediaplayer can’t support RTP playing directly. 5. Audio Recording /usr/share/qt5/examples/multimedia/audiorecorder/audiorecorder This is a widget application, not a QML application. It use QAudioRecorder as its background worker. By default it will use pulsesrc and lamemp3enc to recorder audio as mkv file at user home folder with name of clip_0001.mkv, clip_0002.mkv, and so on. If need special pipeline for recording, example use imxmp3enc to record mp3 files, we need change the function GstElement *QGstreamerCaptureSession::buildEncodeBin in  “src/plugins/gstreamer/mediacapture/qgstreamercapturesession.cpp” as well as QGstreamerMediaContainerControl(QObject *parent) in “src/plugins/gstreamer/mediacapture/qgstreamermediacontainercontrol.cpp” 6. Camera Widgets Application: “/usr/share/qt5/examples/multimediawidgets/camera/camera” QML Application: “/usr/share/qt5/examples/multimedia/declarative-camera/declarative-camera” Qt Multimedia has some bugs on L3.14.52 with QCamera for recording. Use the attached patches: 0001-gstreamer-fix-camerabin-not-negotiated-error.patch 0001-QCamera-can-t-set-recording-container-format-video-a.patch 0002-QtCamera-change-default-encoding-parameters-to-use-N.patch If you want use overlaysink as the preview sink, then use following patch: 0003-use-overlaysink-as-the-preview-sink.patch Both applications need to set environment variable QT_GSTREAMER_CAMERABIN_VIDEOSRC to use imxv4l2src If camera device is other than /dev/video0, set environment variable QT_GSTREAMER_CAMERABIN_VIDEOSRC_DEVICE to the right camera device, such as "/dev/video1" ,  for example: export QT_GSTREAMER_CAMERABIN_VIDEOSRC=imxv4l2src export DISPLAY=:0 export QT_GSTREAMER_CAMERABIN_VIDEOSRC_DEVICE="/dev/video1" By default, the “post-preview” feature of camerabin was disabled by the patches provided, since the imxv4l2src can’t work with “post-preview” internal “videoconvert” element. To enable “post-preview”  feature, one need uncomment following line //g_object_set(G_OBJECT(m_camerabin), POST_PREVIEWS_PROPERTY, TRUE, NULL); in “/qtmultimedia/src/plugins/gstreamer/camerabin/camerabinsession.cpp”, Function: CameraBinSession::CameraBinSession(GstElementFactory *sourceFactory, QObject *parent) And Change “videoconvert” to “imxvideoconvert_g2d” or “imxvideoconvert_ipu” or “imxvideoconvert_pxp” in line : csp = gst_element_factory_make ("videoconvert", "preview-vconv"); of  file “/gstreamer1.0-plugins-bad/gst-libs/gst/basecamerabinsrc/gstcamerabinpreview.c”  function: GstCameraBinPreviewPipelineData *gst_camerabin_create_preview_pipeline (GstElement * element,   GstElement * filter)

Important: If you have any questions or would like to report any issues with the DDR tools or supporting documents please create a support ticket in the i.MX community. Please note that any private messages or direct emails are not monitored and will not receive a response.   This is a detailed programming aid for the registers associated with i.MX 8/8X DDR initialization.  For more details, refer to the i.MX 8/8X main DDR tools page: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX-8-8X-Family-DDR-Tools-Release/ta-p/1121519 Note: Devices with 17-row addresses (R0-R16) are not supported by this SoC.  To reduce the number of attachments, older RPAs may be found in the attached zip file.   ***IMPORTANT: For SCFWv1.7.0, you must use the following RPA versions or later: MX8QM_B0_LPDDR4_RPA_1.6GHz_v23 Older versions of the RPA are not aligned to SCFWv1.7.0.  If trying to use an older version of an RPA with SCFWv1.7.0, it will cause the SCFW not to boot.  The offending lines in the DCD output are as follows: For MX8QM: DATA 4 0xff148000 0x00000885 /* DRC0 bringup */ DATA 4 0xff1a0000 0x00000885 /* DRC1 bringup */ If the user wishes to use an older RPA with SCFW 1.7.0 (not recommended), then the above lines must be removed from older RPA DCD file outputs.  In addition, wrapping these lines are "#ifndef SCFW_DCD", "#else", and "#endif" preprocessor commands.  These should be removed as well.  For example of MX8QM: [remove] #ifndef SCFW_DCD [remove] /* For 1600MHz DDR, DRC 800MHz operation */ [remove] DATA 4 0xff148000 0x00000885 /* DRC0 bringup */ [remove] DATA 4 0xff1a0000 0x00000885 /* DRC1 bringup */ [remove] #else <keep code as is> [remove] #endif  

This document shows the necessary steps to configure the Eclipse IDE for development of Yocto applications. Requirements 1) Linux machine. Ubuntu 12.4 or higher is recommended. 2) Yocto Freescale BSP Release or Freescale Community BSP. For this example we'll use the Freescale BSP Release L3.14.28 but you may use the FSL Community BSP. - Freescale Community BSP FSL Community BSP - Freescale BSP Release  Documentation L3.14.28 (login required) https://www.freescale.com/webapp/Download?colCode=L3.14.28_1.0.0_LINUX_DOCS&location=null&fpsp=1&WT_TYPE=Supporting%20In… 3) Poky Meta Toolchain (Poky 1.7 / L3.14.28 for our example but you should use the toolchain that corresponds to the BSP that will be used) For information on how to extract and install the meta toolchain please follow the steps on the next document. Task #7 - Create the toolchain 4) Eclipse Luna. We’ll use the Luna SR2 (4.4.2) version of the Eclipse IDE. You may find it on the following website: http://www.eclipse.org/downloads/packages/release/luna/sr2 Look for the “Eclipse IDE for C/C++ Developers”, which contains the Eclipse Platform, the Java Development Tools (JDT), and the Plug-in Development Environment. Once you have downloaded the tarball extract it. The following command unpacks and installs the downloaded Eclipse IDE tarball into a clean directory using the default name eclipse:      $ cd ~      $ tar -xzvf ~/Downloads/eclipse-cpp-luna-SR2-linux-gtk-x86_64.tar.gz Configuring the Eclipse IDE Once with Eclipse Luna installed you may run the Eclipse IDE with the following command: $ cd eclipse $ ./eclipse Select a new workspace. Chose "Install New Software" from the "Help" pull-down menu. Select the "Luna - http://download.eclipse.org/releases/luna" Find and expand the Linux Tools option and select: Linux Tools LTTng Tracer Control Linux Tools LTTng Userspace Analysis LTTng Kernel Analysis If some of these options are not listed it means that they are already installed. (To change this you may uncheck the Hide items that are already installed box) Find and expand the Mobile and Device Development and select the following:   C/C++ Remote Launch (Requires RSE Remote System Explorer)   Remote System Explorer End-user Runtime   Remote System Explorer User Actions   Target Management Terminal (Core SDK)   TCF Remote System Explorer add-in   TCF Target Explorer If some of these options are not listed it means that they are already installed. (To change this you may uncheck the Hide items that are already installed box) Expand Programming Languages and select:   C/C++ Autotools Support   C/C++ Development Tools Chose Next and accept the necessary EULA Clck on the Finish button. The selected packages will be downloaded and installed. You will be asked to restart Eclipse IDE to finish the installation. Adding the Yocto Plug-in to the Eclipse IDE Next step is to install the Eclipse Yocto Plug-in into the Eclipse IDE. We'll show how to install the pre-built plug in. Start the Eclipse IDE In Eclipse, select "Install new Software" from the "Help" menu Click the "Add..." button to add a repository and enter: Name: Any name, we will use Yocto Fio Location: http://downloads.yoctoproject.org/releases/eclipse-plugin/1.8/luna Click "Ok" and then chose this new repository on the "Work with" drop-down menu and select the following plug-ins from the list:   Yocto Project ADT Plug-in   Yocto Project Bitbake Commander Plug-in   Yocto Project Documentation plug-in Install these plug-ins and click "OK" when prompted about installing software that contains unsigned content. You may be asked to restart the Eclipse IDE. Configuring the Eclipse Yocto Plug-in With all the necessary packages installed we'll now configure the Eclipse Yocto Plug-in. In this steps we will configure the Cross Compiler options and the Target options. These will then be used as default for your projects from within your working workspace. Select "Preferences" from the "Window" menu. Click on Yocto Project ADT from the left options and then under Cross Compiler Options select the Standalone pre-built toolchain radio button. We need to point to the Toolchain Root location of our installed toolchain. This is covered on the following community document: Task #7 - Create the toolchain In this case we'll be using poky 1.7 tollchain which has the following default location: /opt/poky/1.7 As fo the Sysroot Location this would correspond to your build directory sysroot folder, which is located on the following path: <YOCTO_BSP_DIR>/<BUILD_DIR>/tmp/sysroots/<MACHINE> In our case our Tartget architecture would be the Cortex-A9, which correspond to the i.MX6 and which is also the only option installed on the chosen directory. For Target Options we would be using the actual HW in order to test our application so keep the External HW option selected. Creating a Hello World Project We are now ready to create our project. Just to test our configuration we'll create a Hello World project.We can do so by selecting File->New->C Project or C++ Project We must then select a Project name and in project type we can chose either an Empty project or as in our case a Hello World Project, all this under the Yocto Project ADT Autotools Project folder. We will have the GNU Autotools Tolchain selected. The next screen will show some of the Basic Properties for our project, including the GNU license. Fill these as required. You may clock on Finish at this point. We should see that the HelloWorld project was created. We should right-click on the project folder and then chose Reconfigure Project in order to fill the necessary libraries. After this is completed we can build our project either by choosing the hammer icon or in the Build Project option inside the Project menu. We can look for correct competition or any errors or warning on the Console tab. Further Application Development After this basic setup you may work on more complex examples like a GPU and a Gstreamer Application examples on the following nicely written document: Yocto Application Development Using Eclipse IDE

We are very proud to announce that Element14's SabreLite i.MX6Q board is now officially supported by Adeneo Embedded's i.MX6 WEC7 BSP. As a consequence, our customers are able to use the SabreLite board from Element14 as well as the one from Boundary Devices. Follow this link for Adeneo Embedded's i.MX6 WEC7 BSP Follow this link for Element 14's SabreLite board Ce document a été généré à partir de la discussion suivante : Element14's SabreLite board officially supported by Adeneo Embedded's i.MX6 WEC7 BSP