This doc will show: i.MX6SLL EVK board without connect hardware LCD display, using FreeRDP to share screen to remote PC which in same network, PC take this shared screen could run any command on i.MX6SLL EVK board. HW: i.MX6SLL EVK board, PC, usb network adapter SW: i.MX6SLL Linux 5.15.72_2.2.0 BSP release, and code change in this doc 1>yocto-5.15.72/6sll-bld/conf/local.conf, add below line, as freerdp depend on ffmpeg. LICENSE_FLAGS_ACCEPTED+="commercial" 2>pixman need switch to 0.42.0, enter folder yocto-5.15.72/6sll-bld/tmp/work/cortexa9t2hf-neon-poky-linux-gnueabi/pixman/1_0.40.0-r0/pixman-0.40.0, fetch latest 0.42.0 version code from https://github.com/freedesktop/pixman.git 3>freerdp need use 2.8.0, enter folder yocto-5.15.72/6sll-bld/tmp/work/cortexa9t2hf-neon-poky-linux-gnueabi/freerdp/1_2.6.1-r0/git should checkout to 2.8.0 tag; then to use neon accelerate freerdp related function, such as color space conversion, image codec encoding, apply patch freerdp-codechange-neon.diff. 4>Enter yocto-5.15.72/sources/meta-openembedded/meta-oe/recipes-support/freerdp, file freerdp_2.6.1.bb change as freerdp-2.6.1-bbfile.diff 5> bitbake -c compile ffmpeg bitbake -c install ffmpeg bitbake -c compile pixman bitbake -c install pixman bitbake -c compile freerdp bitbake -c install freerdp 6> Copy generated new libs to i.MX6SLL Linux rootfs: cp /root/imx6sllevk-linux-lib/lib* /usr/lib/ cd /usr/lib/ rm libfreerdp-client2.so.2 libfreerdp2.so.2 libpixman-1.so.0 libwinpr-tools2.so.2 libwinpr2.so.2 ln -s libfreerdp-client2.so.2.8.0 libfreerdp-client2.so.2 ln -s libfreerdp2.so.2.8.0 libfreerdp2.so.2 ln -s libpixman-1.so.0.42.0 libpixman-1.so.0 ln -s libwinpr-tools2.so.2.8.0 libwinpr-tools2.so.2 ln -s libwinpr2.so.2.8.0 libwinpr2.so.2 ln -s libavcodec.so.58.134.100 libavcodec.so.58 ln -s libavutil.so.56.70.100 libavutil.so.56 ln -s libswresample.so.3.9.100 libswresample.so.3 Make sure: libfreerdp-client2.so.2 -> libfreerdp-client2.so.2.8.0 libfreerdp2.so.2 -> libfreerdp2.so.2.8.0 libwinpr-tools2.so.2 -> libwinpr-tools2.so.2.8.0 libwinpr2.so.2 -> libwinpr2.so.2.8.0 libswresample.so.3 -> libswresample.so.3.9.100 libavutil.so.56 -> libavutil.so.56.70.100 libavcodec.so.58 -> libavcodec.so.58.134.100 7>i.MX6SLL Linux OS, file /etc/xdg/weston/weston.ini, change start-on-startup to true [screen-share] command=WLOG_APPENDER=file WLOG_FILEAPPENDER_OUTPUT_FILE_NAME=output.log WLOG_FILEAPPENDER_OUTPUT_FILE_PATH=/tmp /usr/bin/weston --backend=rdp-backend.so --shell=fullscreen-shell.so --no-clients-resize --rdp-tls-cert=/etc/freerdp/keys/server.crt --rdp-tls-key=/etc/freerdp/keys/server.key start-on-startup=true 8> i.MX6SLL Linux OS, run below cmd: mkdir /etc/freerdp mkdir /etc/freerdp/keys /root/imx6sllevk-linux-lib/winpr-makecert -path /etc/freerdp/keys mv /etc/freerdp/keys/imx6sllevk.crt /etc/freerdp/keys/server.crt mv /etc/freerdp/keys/imx6sllevk.key /etc/freerdp/keys/server.key service weston stop service weston start 9>Plug usb network adapter to i.MX6SLL EVK board J10; i.MX6SLL board and PC must in same network, ping without problem. i.MX6SLL Linux OS, there are two process name as "weston", one process is weston rdp backend will share screen to PC. If only one weston process, need check did miss copy any new lib or check libary file name. 10>PC side: wfreerdp.exe /v:IPADDRESS_OF_IMX6SLLEVK There will prompt dialog box for user name and password, just press ESC, then PC side will show i.MX6SLL Linux desktop screen; Click console button of i.MX6SLL Linux OS desktop, within that console input any i.MX6SLL Linux OS cmd, check result of it from PC side. Known issue: wfreerdp.exe is downloaded from https://ci.freerdp.com/job/freerdp-nightly-windows/ If run latest wfreerdp.exe but show nothing of remote desktop, try attached version wfreerdp.exe(3.0.0-dev). Also you can try check log files first: i.MX6SLL Linux OS file /tmp/output.log; PC side generated log file as: wfreerdp.exe /v:IPADDRESS_OF_IMX6SLLEVK /log-level:TRACE > rdp.log Reference: 1>https://www.nxp.com/design/software/embedded-software/i-mx-software/embedded-linux-for-i-mx-applicat... 2>https://github.com/FreeRDP 3>https://github.com/freedesktop/pixman 4>https://github.com/DLTcollab/sse2neon    

Many customer set GPIO as input or output functions. While they are confused on how to set GPIO property. This article describe on GPIO property setting tips, especially that input and out property setting are different. 

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

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

This is ov5645 driver and tested with i.MX6 L3.0.35 BSP .  It is modified based on ov5640.c. P.S. The power down function for OV5645 is different from the OV5640. So modify the function in your_board.c like this: static void mx6q_mipi_powerdown(int powerdown) {     if (!powerdown)         gpio_set_value(MIPI_PWDN, 1);     else         gpio_set_value(MIPI_PWDN, 0);     msleep(5); }

This is an example of QR code encoding using i.MX28. The encoded QR image can show on the LCD display directly using frame buffer and the image saved as a BMP file. Board : i.MX28EVK BSP : L2.6.35_1.1.0_130130_source QR Code Lib:  qrencode-3.4.4.tar.gz Download from https://fukuchi.org/works/qrencode/ Libqrencode is a C library for encoding data in a QR Code symbol. This library is a free software made by Kentaro Fukuchi. Build the QR Code Lib source code into rootfs. 1. Create a new folder in <ltib>/dist/lfs-5.1/.     e.g. <ltib>/dist/lfs-5.1/qrencode 2. Copy the qrencode.spec to this new created folder 3. Build the source code    ./ltib –p qrencode.spec –m prep    ./ltib –p qrencode.spec –m scbuild    ./ltib –p qrencode.spec –m scdeploy Create and build the application in unit_test: - I use the existing unit_test package to build my application code. 1. Extract the source code of unit_test    ./ltib –p imx-test –m prep 2. cd <ltib>/rpm/BUILD/imx-test-2.6.35.3-1.1.0/test 3. mkdir qr_test 4. copy the Makefile and qr_test.c to qr_test folder 5. Build the unit_test     ./ltib –p imx-test  –m scbuild     ./ltib –p imx-test  –m scdeploy After built the code successfully, the qr_test.out will be generated in the unit_test folder. I start the board with NFS, so I can run the qr_test.out on the board directly. The command is : ./qr_test.out   (the default QR encode text is “http://www.freescale.com”) Or input the new text like this : ./qr_test.out –t https://community.freescale.com/community/imx The QR code  show on the display: And the BMP files will be generated in the unit_test folder.

Introduction The SABRE Board for Smart Devices Based on the i.MX 6 Series is an evalutaion board featuring the i.MX6 Quad Core Cortex-A9 processor. Freescale ported the Linux Operating System (as of this writing version 3.0.35) and the Board Support Package (BSP) containing the Linux Kernel, build system called LTIB, GCC compiler tools, boot loader, u-boot, and root file system is available for download, install, and build. LTIB is a perl script and is the acroynm for Linux Target Image Builder. This document describes setting up a CentOS 6.3 64-bit host in a virtual machine for using the BSP and running the images on i.MX6Q-SDB evaluation board. References Description Reference CentOS 6.3 LiveCD installed in a virtual machine from virtual box. http://centos.org CentOS-6.3-x86_64-LiveCD.iso 9953ff1cc2ef31da89a0e1f993ee6335 Virtual Box - A Virtual Machine used for creating the CentOS host. Virtual Box installed on Windows 7 64-bit Pro, then create the VM. Allocated 20 GB Hard disk and 1 MB RAM. The steps for installations are found at the virtual box web site. http://www.virtualbox.org The BSP provides, a build system called ltib, GNU tools, U-Boot, Linux Kernel, and root file system: Download archive from http://freescale.com/sabresdb L3.0.35_12.09.01.0_GA_source.tar.gz 5ab4198278e92e03be74ca602227afad Document Conventions Bold lines are Linux commands and edits run on CentOS. The '$' indicates running the command as a regular user The '#' indicates running the command as root user. CentOS Host Setup For this example a virtual machine is used, however a dedicated PC running only CentOS linux could be used. 1. Add user login to sudo'ers file           Login as user root and run the visudo command          # visudo           Add the following line and save the file:           user     ALL=(ALL)     ALL 2. Update the system packages:           $ sudo yum udpate 3. Install package for "ltib" operations:           $ sudo yum install make gcc gcc-c++ kernel-devel bison libuuid-devel ncurses-devel zlib-devel lzo-devel intltool libtool tcl rpm-build perl-ExtUtils-MakeMaker ld-linux.so.2 zlib-1.2.3-27.el6.i686 4. Update sudo'ers file for supporting ltib rpm           $ sudo visudo           Add the following line and save the file:           user     ALL=NOPASSWD: /bin/rpm,/opt/freescale/ltib/usr/bin/rpm Install BSP The sources are in a tar gziped archive file which is downloaded from http://freescale.com/sabresdb, selecting the Software & Tools tab then expanding Run-time Software in the middle of the page. A free login is required for download which can be registered for by selecting the Login at the top right of the freescale.com page. Once downloaded, verify the md5 checksum (see references above for the value). $ mkdir ~/imx6 $ tar -zxf L3.0.35_12.09.01.01_GA_source.tar.gz -C ~/imx6 $ cd ~/imx6/*source $ ./install Read and accept the licensing information. Choose a directory to install too, for this example entered .. which is the parent directory. Build the i.MX6Q SDB $ cd ~/imx6/ltib $ ./ltib After some time (depends on how fast your host computer is) the menuing system is shown which allows you to select build configurations. The second screen selects the development platform which is imx6q for the SDB. For this example the Min profile is chosen which is the default. Use the arrow keys to move and the enter key to select. The space bar selects/deselects an entry. Use the right arrow key to move to <Exit> and press the enter key. The save dialog box is presented, save. The next menu is the iMX6x Base Boards which leaving all as default except for the U-boot board selection which is mx6q_sabresd for the SDB. Save and exit. Images When ltib completes, the images are found in <ltib>/rootfs/boot. Bootloader = u-boot.bin Linux Kernel = uImage File system = </ltib>/rootfs

Please make sure design is follow below checking list before checking this guide. HW Design Checking List for i.MX6DQSDL

DirectFB DirectFB is a thin library that provides hardware graphics acceleration, input device handling and abstraction, integrated windowing system with support for translucent windows and multiple display layers, not only on top of the Linux Framebuffer Device. It is a complete hardware abstraction layer with software fallbacks for every graphics operation that is not supported by the underlying hardware. DirectFB adds graphical power to embedded systems and sets a new standard for graphics under Linux. [Source: directfb.org] DirectFB Quick Test Select DirectFB in Package List on LTIB1011: [x] DirectFB Select also DirectFB examples: [x] DirectFB examples Build your Linux. Flash your SD card. Launch your Linux image on your board, and then launch a DirectFB example: $ df_dok DirectFB benchmark is launched. Benchmark result on an i.MX 53 EVK:

Wondering how to manage and install the various rpms generated under tmp/deploy/rpm? smart is the application you need on the target to replace apt-get Please set your local.conf with the following: # It is also recommended you use build history, which adds some sanity checks to package versions, in conjunction with the server that # is running the PR Service. To enable build history, add the following to each building system's # It is recommended to activate "buildhistory" for testing the PR service INHERIT += "buildhistory" BUILDHISTORY_COMMIT = "1" PRSERV_HOST = "localhost:0"  # This will set up your host computer as Package Revision Server // PACKAGE_FEED_URIS = "http://10.170.96.7/imx7rpm" #please place any server ip addr, this one is mine. add also the following to enable the package management (smart): EXTRA_IMAGE_FEATURES += "package-management" Setup your own http server, and link the server repository with your tmp/deploy/rpm repo (your are free to use your preferred http server). Since Morty (yocto 2.4), smart has been deprecated, and now the package management is done with dnf (from Debian). Please check dnf document to get more to know about dnf. The dependencies are still poorly controlled. After compiling a pkg the easiest remain: dnf install package.rpm example: root@imx8mmevk:~# dnf install libfuse2-2.9.7-r0.aarch64.rpm Failed to synchronize cache for repo 'oe-remote-repo-imx8m-imx8mqevk-arm', disabling. Dependencies resolved. ===============================================================================================================  Package                  Arch                    Version                   Repository                    Size =============================================================================================================== Installing:  libfuse2                 aarch64                 2.9.7-r0                  @commandline                  56 k Transaction Summary =============================================================================================================== Install  1 Package Total size: 56 k Installed size: 212 k Is this ok [y/N]: y Downloading Packages: Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction   Preparing        :                                                                                       1/1   Installing       : libfuse2-2.9.7-r0.aarch64                                                             1/1   Running scriptlet: libfuse2-2.9.7-r0.aarch64                                                             1/1 /sbin/ldconfig: /usr/lib/libOpenVG.so is not a symbolic link   Verifying        : libfuse2-2.9.7-r0.aarch64                                                             1/1 Installed:   libfuse2.aarch64 2.9.7-r0 Complete!

The PICO-PI-IMX7 is a TechNexion board defined here. It is now supported in mainline U-Boot, mainline Kernel, FSL Community BSP and Buildroot. In mainline U-Boot it is supported since v2017.07. In mainline Linux Kernel it is supported since 4.13. To generate an image for PICO-PI-IMX7 using FSL Community BSP, please see: The imx7d-pico board is now supported in FSL Community BSP - i.MXDev Blog. To generate an image for PICO-PI-IMX7 using Buildroot, please see: The imx7d-pico board is now supported in Buildroot - i.MXDev Blog.

Q: i.Mx53 and a kernel based on our latest Linux BSP (Kernel Version 2.6.35) – They do see problems when mounting SATA Disk which is used for their rootfs. Has anyone seen this before? I am just wondering if the upcoming release might address and fix this? From the MCU i MX Product Update Call_May 2013.ppt presentation i.MX53  external release June 30 th 2013, freescale.com •       There will be patches/features for i.MX53 including Yocto for this kernel  L2.6.35 BSP release •       Validation testing Where can I check which patches / features are in this release? Is there already a Release Note? this is the kernel for the legacy release: http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/log/?h=imx_2.6.35_maintain The main proposal for the next legacy release is not upgrade kernel, is only make a yocto release. And if you take meta-fsl-arm on master you will find everything from legacy release. I upstreamed every change I made internaly A: Rootwait is in the command line. Please note they can boot with Kernel version 3.2 - but customer requires 2.6.35 Kernel for other reasons. Please find attached the log files I received. A text bootlog (note sometimes booting works) but it is not stable and reliable on 2.6.35 - same HW seems stable on 3.2 Kernel Regarding to the failed messages contained in customer's log, it's a random issue. SATA driver reports that there is an " SError: { DevExch }" on the PHY connection. It seems that the SATA PHY connection is not stable enough. Can you make a double check on the cable connection and the power supply? You can disable the following configuration when build the 2.6.35 kernel image config SATA_AHCI_FSL_NO_HOTPLUG_MODE         bool "Freescale i.MX SATA AHCI NO HOTPLUG mode"         depends on SATA_AHCI_PLATFORM != n         default n         help           In order to decrease the pwr consumption, release the CLK resources such as usb_phy1_clk, when there is no SATA device adaptored into the AHCI SATA port. The HOTPLUG feature can't be enabled in this situation. Please disable this option if the HOTPLUG is mandatory required.           If unsure, say N. ============================ BTW, I just verified the RFS on SATA on i.MX53 LOCO. It's ok. Here is the log: Starting kernel ... Initializing cgroup subsys cpuset Initializing cgroup subsys cpu Linux version 2.6.35.3-01275-ge6b3f3b (r65037@shlinux1) (gcc version 4.7.3 20121001 (prerelease) (crosstool-NG hg+-946d6d133a90) ) #52 PREEMPT Tue Jul 30 11:27:17 CST 2013 CPU: ARMv7 Processor [412fc085] revision 5 (ARMv7), cr=10c53c7d CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: Freescale MX53 LOCO Board Memory policy: ECC disabled, Data cache writeback Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 250880 Kernel command line: noinitrd console=ttymxc0,115200 root=/dev/sda1 rootwait rw ... mxc_rtc mxc_rtc.0: setting system clock to 1970-01-01 00:00:01 UTC (1) Waiting for root device /dev/sda1... ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) ata1.00: ATA-8: SanDisk SSD P4 32GB, SSD 8.00, max UDMA/133 ata1.00: 62533296 sectors, multi 1: LBA48 ata1.00: configured for UDMA/133 ata1: EH complete scsi 0:0:0:0: Direct-Access     ATA      SanDisk SSD P4 3 SSD  PQ: 0 ANSI: 5 sd 0:0:0:0: [sda] 62533296 512-byte logical blocks: (32.0 GB/29.8 GiB) sd 0:0:0:0: [sda] Write Protect is off sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sd 0:0:0:0: [sda] Attached SCSI disk VFS: Mounted root (ext2 filesystem) on device 8:1. Is there a possibility to tweak timing parameters? Maybe that could help to get it more robust? Are there other parameters we can try to play with and could explain failing Sata RFS on some i.Mx53 boards? I got more info from customers and also "hints" to other forum entries realted to that problem. http://lists.debian.org/debian-arm/2012/03/msg00059.html http://debian.2.n7.nabble.com/Linux-2-6-35-3-Kernel-for-ARM-and-SATA-problems-td1664800.html """ Linux version 2.6.35.3-mx53qsb (mike@ubuntu) (gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) ) #3 PREEMPT Sat Mar 17 15:34:48 PDT 2012 CPU: ARMv7 Processor [412fc085] revision 5 (ARMv7), cr=10c53c7f CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache Machine: Freescale MX53 LOCO Board ... ata1: SATA max UDMA/133 irq_stat 0x00000040, connection status changed irq 28 ... ata1: SATA link down (SStatus 1 SControl 300) ata1: exception Emask 0x10 SAct 0x0 SErr 0x4000000 action 0xe frozen t4 ata1: irq_stat 0x00000040, connection status changed ata1: SError: { DevExch } ata1: hard resetting link ata1: SATA link down (SStatus 1 SControl 300) ata1: EH complete """ http://www.raspberrypi.org/phpBB3/viewtopic.php?f=9&t=4256&start=175 As mentioned custoemr sees simlar problems with our test image. Maybe one way to check, can you provide me our u-boot and uImae you did the test with? Customer confirmed their HW is compatible with MX53 LOCO Board so I would like to make sure they use correct SW and use what you tested. A bit strange is also that this Problem shows never up on a 3.2 based kernel. However the end customer requires to stay on 2.6.35 for other reasons. - kernel 3.2 which is able to initialize always. - protocol logs for good and bad case trans -p uImage.mx5.35 File keyword is ngbl7927a Data transfer to Austin Transcend repository started.   File size is 2.94 MB. Transfer Method:  Serial with no encryption. File 'uImage.mx5.35' (size 2.94 MB) transcended. Retrieve the file with the keyword:  ngbl7927a TransWeb URL:  http://transweb.freescale.net/index.cgi?go=KEYWORD&KEYWORD=ngbl7927a This file will be deleted in three working days. Local Deletion Time:  Thu Aug 15 23:51:16 2013 CST Greenwich Mean Time:  Fri Aug 16 04:51:16 2013 GMT I know that i.MX53 SATA doesn't have the adjust-window like the adjust window contained by i.MX6Q SATA. As I know that we didn‘t release 3.2 kernel version BSP, right? Regarding to the experience of ”http://debian.2.n7.nabble.com/Linux-2-6-35-3-Kernel-for-ARM-and-SATA-problems-td1664800.html”, it seems that the updates of the SATA stack of Linux level up the timing-compatibility of SATA. Derived from the URL listed above. ”I did trace the problems I having to the ahci code in the kernel not properly handling an ahci CONINIT event generated by my WD5000BEVT drive.  Seems this drive has extra SATA features implemented so that it can be used in hot-plug arrays and these features aren't recognized by the kernel driver so it just seems to shut down the drive and ignore it.  The other SATA drive that I do have working with the kernel doesn't implement the extra features so the kernel is happy.  Presumably these problems were fixed in later kernels and the patches didn't make it into Freescales 2.6.35.3 branch. On the other hand, the kernel might be fine and the firmware in the drive isn't conforming to the ahci specs, but I think that wold cause problems with the drive on other systems. ” This document was generated from the following discussion: i.MX53 Sata rootfs problem

This example is useful  if you have your device connected to a host machine using a USB cable, and you want your host machine to be able to update your device using a protocol ready to go. Information you need prior to using this example Fastboot is a protocol used to update firmware in Android devices from a host over USB; Freescale implements fastboot as a uboot driver for the device and the implementation is available from patches applied to uboot source code; By default, fastboot is only enabled when building uboot to use with an Android BSP; To run fastboot at the device in default implementation you need to call it from uboot command line (using the debug serial port of the slave device, for example); The host fastboot application is available as source code from Google. You can build your own fastboot(.exe) binary (which is not in the scope of this howto), or you can find a binary ready for you to go searching the web; You are required to be familiar with Linux BSP and have i.MX53 BSP version 11.05 installed. With this information in mind, what do you get from this example? Patch for uboot to enable fastboot driver for iMX53 Quick Start Board with a new spec file; A command line application that set a flag in iMX53 to automatically start fastboot after a reset, either if it is a SOFT or a HARD reset. How to prepare the example Copy uboot patch file (attached) to /opt/freescale/pkgs; Replace your uboot spec file (u-boot.spec.in attached) in <bsp_root>/ltib/config/platform/imx/; Build a system image for iMX53 Quick Start Board with the packages you need; Build the command line application (setbootmode.c attached) using ltib shell; Prepare an SD card copy the command line application /usr/sbin in your SD card system partition. See attachment to this page. How to test the example Boot the Quick Start Board with the SD card you prepared; Login as root using a serial cable and a terminal application; Run setbootmode application as follows: $ setbootmode 1 Reboot the system: $ reboot After rebooting, the device will automatically run fastboot from uboot and will wait for a connection from the host machine. You can test the connection using a fastboot binary at the host machine (not provided here). Even if you HARD reset your hardware, your device will keep running fastboot at startup. If you want to go back to a regular boot operation, you need to cut power supply to your board. How does the magic happen? The setbootmode application sets the LSB in the Low Power General Register (LPGR) of the Secure Real Time Clock (SRTC) module to true. The patched version o uboot tests for this bit as a flag to run fastboot or not. The magic is that the LPGR is persistent, even during reset. Additional tips You can run setbootmode with no arguments to see its options; You need to set the boot mode to 0 after a successful update to avoid entering fastboot mode again after a new reboot; Partitioning of the device seen by fastboot is not implemented; Besides using setbootmode, you can read/set LPGR using either md.l / nm.l in uboot or devmem2 at command line: uboot-> md.l 0x53fa401c 1 - displays LPGR; uboot-> nm.l 0x53fa401c - presents a prompt for you to change LPGR; linux shell-> devmem2 0x53fa401c w - displays LPGR; linux shell-> devmem2 0x53fa401c w <value> - changes LPGR; devmem2 has issues that you need to fix so that you can use it to change LPGR: include "volatile" in all writing instruction; uncomment 'w' write instruction.

Hello everyone! In this document you'll find an example on how to build your Cortex-M33 code where some parts of the code runs from DDR, for this changes on ATF where the M33 core can visit DRAM in early stage. For this we will take advantage of RPROC framework, RPROC (Remote Processor Framework) is a Linux kernel and U-Boot subsystem that manages secondary, embedded processors (like Cortex-M cores), where we will use the A55 to load the M33 firmware. This will require changes on Linux device tree, ATF and M33 linker file. Requirements: Ubuntu 20.04 or later host PC i.MX93 QSB UUU Tool ARM GNU Toolchain (arm-gnu-toolchain-12.3.rel1-x86_64-aarch64-none-linux-gnu) SDK package (SDK_25_09_00_MCIMX93-QSB) Prebuild Linux Image (LF_v6.12.34-2.1.0_images_IMX93EVK) ### Clone imx-mkimage, it is better to download the same version of the sw we are working with ### $ git clone https://github.com/nxp-imx/imx-mkimage -b lf-6.12.34-2.1.0 ### Decompress the GNU toolchain into a path in local disk, in this test would be /opt/ ### $ sudo tar -xvJf arm-gnu-toolchain-12.3.rel1-x86_64-aarch64-none-linux-gnu.tar.xz -C /opt ### Clone and build Uboot ### $ git clone https://github.com/nxp-imx/uboot-imx -b lf-6.12.34-2.1.0 $ cd uboot-imx $ make -j $(nproc --all) clean $ make -j$(nproc --all) ARCH=arm CROSS_COMPILE=/opt/arm-gnu-toolchain-12.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu- imx93_11x11_evk_defconfig $ make -j $(nproc --all) ARCH=arm CROSS_COMPILE=/opt/arm-gnu-toolchain-12.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu- ### Download and extract ELE firmware ### $ cd .. $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-ele-imx-2.0.3-286c884.bin $ chmod +x firmware-ele-imx-2.0.3-286c884.bin $ ./firmware-ele-imx-2.0.3-286c884.bin --auto-accept ### Optional if using i.MX FW ### $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.29-8741a3b.bin $ chmod +x firmware-imx-8.29-8741a3b.bin $ ./firmware-imx-8.29-8741a3b.bin --auto-accept ### Clone ATF ### $ git clone https://github.com/nxp-imx/imx-atf -b lf-6.12.34-2.1.0 $ cd imx-atf ### Modify ATF for the M33 to be able to access DDR ###   --- a/plat/imx/imx93/trdc_config.h +++ b/plat/imx/imx93/trdc_config.h struct trdc_mrc_config trdc_n_mrc[] = { { 0, 0, 0, 0x80000000, 0x80000000, 0, false }, /* MRC0 DRAM for S400 DID0 */ { 0, 1, 0, 0x80000000, 0x80000000, 0, false }, /* MRC0 DRAM for MTR DID1 */ - { 0, 2, 0, 0x80000000, 0x80000000, 0, true }, /* MRC0 DRAM for M33 DID2 */ + { 0, 2, 0, 0x80000000, 0x80000000, 1, true }, /* MRC0 DRAM for M33 DID2 */ { 0, 3, 0, 0x80000000, 0x80000000, 1, false }, /* MRC0 DRAM for A55 DID3 */ { 0, 5, 0, 0x80000000, 0x80000000, 0, false }, /* MRC0 DRAM for USDHC1 DID5 */ { 0, 6, 0, 0x80000000, 0x80000000, 0, false }, /* MRC0 DRAM for USDHC2 DID6 */ ### Build modified ATF ### $ make -j $(nproc --all) PLAT=imx93 bl31 CROSS_COMPILE=/opt/arm-gnu-toolchain-12.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu- ### Modify linker file and build M33 code, in this example we are using hello world SDK example ### $ cd .. $ tar -xvzf SDK_25_09_00_MCIMX93-QSB.tar.gz $ cd SDK_25_09_00_MCIMX93-QSB/boards/mcimx93qsb/demo_apps/hello_world/armgcc --- a/boards/mcimx93autoevk/demo_apps/hello_world/armgcc/MIMX9352_cm33_ram.ld +++ b/boards/mcimx93autoevk/demo_apps/hello_world/armgcc/MIMX9352_cm33_ram.ld m_a55_suspend_ram (RW) : ORIGIN = 0x20002000, LENGTH = 0x00001000 m_data (RW) : ORIGIN = 0x20003000, LENGTH = 0x0001B000 m_rsc_tbl (RW) : ORIGIN = 0x2001E000, LENGTH = 0x00001000 + m_text_dram (RW) : ORIGIN = 0x8F000000, LENGTH = 0x00001000 + m_data_dram (RW) : ORIGIN = 0x8F001000, LENGTH = 0x00001000 } /* Define output sections */ . = ALIGN(4); } > m_text + .dram_text : + { + . = ALIGN(32); + *(.myDRAM) + . = ALIGN(32); + } > m_text_dram + .ARM.extab : { *(.ARM.extab* .gnu.linkonce.armextab.*) .ARM.attributes 0 : { *(.ARM.attributes) } ASSERT(__StackLimit >= __HeapLimit, "region m_data overflowed with stack and heap") + + .dram_data : + { + . = ALIGN(32); + *(.myDRAM_data) + . = ALIGN(32); + } > m_data_dram } a/boards/mcimx93autoevk/demo_apps/hello_world/hello_world.c +++ b/boards/mcimx93autoevk/demo_apps/hello_world/hello_world.c * Definitions ******************************************************************************/ +#define _RET_IP_ (unsigned long)__builtin_return_address(0) +#define _THIS_IP_ ({ __label__ __here; __here: (unsigned long)&&__here; }) /******************************************************************************* * Prototypes /******************************************************************************* * Variables ******************************************************************************/ - +const char myString[] __attribute__((section(".myDRAM_data"))) = "Hello, World!"; /******************************************************************************* * Code ******************************************************************************/ +__attribute__ ((section(".myDRAM"))) +void Dram_test(void) { + PRINTF("Dram_test!!\r\n"); + + PRINTF("%s!!\r\n", myString); + + PRINTF("function %p\n",_THIS_IP_); +} + /*! * @brief Main function */ BOARD_BootClockRUN(); BOARD_InitDebugConsole(); - PRINTF("hello world.\r\n"); + PRINTF("hello world from DRAM.\r\n"); while (1) { ch = GETCHAR(); PUTCHAR(ch); + if(ch == 'a'){ + Dram_test(); + } } } $ export ARMGCC_DIR=~/gcc-arm-none-eabi-10.3-2021.10 $ export PATH=$PATH:~/gcc-arm-none-eabi-10.3-2021.10 $ ./build_release.sh ### Copy the resulting binaries to imx-mkimage ### $ cp ~/imx-atf/build/imx93/release/bl31.bin ~/imx-mkimage/iMX93 $ cp ~/uboot-imx/u-boot.bin ~/imx-mkimage/iMX93 $ cp ~/uboot-imx/spl/u-boot-spl.bin ~/imx-mkimage/iMX93 ### Copy i.MX firmware ### $ cd .. $ cp firmware-imx-8.29-8741a3b/firmware/ddr/synopsys/lpddr4_dmem_* ~/imx-mkimage/iMX93 $ cp firmware-imx-8.29-8741a3b/firmware/ddr/synopsys/lpddr4_imem_* ~/imx-mkimage/iMX93 $ cpfirmware-ele-imx-2.0.3-286c884/mx93a1-ahab-container.img ~/imx-mkimage/iMX93 ### Build the flash.bin using mkimage $ cd imx-mkimage $ make SOC=iMX93 flash_singleboot ### Clone, modify and build device tree for Linux to be able to use RPROC to load M33 Firmware ### $ git clone https://github.com/nxp-imx/linux-imx -b lf-6.12.34-2.1.0 --- a/arch/arm64/boot/dts/freescale/imx93-9x9-qsb.dts +++ b/arch/arm64/boot/dts/freescale/imx93-9x9-qsb.dts no-map; }; + dram: dram@20480000 { + reg = <0 0x8f000000 0 0x20000>; + no-map; + }; + rsc_table: rsc-table@2021e000 { reg = <0 0x2021e000 0 0x1000>; no-map; <&mu1 1 1>, <&mu1 3 1>; - memory-region = <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>, + memory-region = <&dram>, <&vdevbuffer>, <&vdev0vring0>, <&vdev0vring1>, <&vdev1vring0>, <&vdev1vring1>, <&rsc_table>; fsl,startup-delay-ms = <500>; status = "okay"; $ export ARCH=arm64 $ export CROSS_COMPILE=/opt/arm-gnu-toolchain-12.3.rel1-x86_64-aarch64-none-linux-gnu/bin/aarch64-none-linux-gnu- $ make imx_v8_defconfig $ make freescale/imx93-9x9-qsb.dtb Set SW for serial download on the QSB (0001), connect debug, download and power cables and turn on the QSB, for this test we will flash the demo image and just replace Linux device tree, flash.bin and M33 firmware into the QSB board. $ uuu -b sd_all flash.bin imx-image-full-imx93evk.wic Once it is done change SW to the respective bootmedia SD boot (0011) and boot the board and stop at uboot, to enter fastboot mode to load modified device tree and M33 firmware > fastboot 1 After this just run UUU tool on the host computer and fatload the files $ uuu -b fat_write imx93-9x9-qsb.dtb mmc 1:1 $ uuu -b fat_write hello_world.elf mmc 1:1 When the tool finish, stop fastboot mode by typing CTRL+C and then boot into Linux > boot Login with default password "root" and run the following commands to load M33 firmware $ root $ modprobe imx_rpmsg_tty $ cp /run/media/boot-mmcblk1p1/hello_world.elf /lib/firmware/ $ echo hello_world.elf > /sys/class/remoteproc/remoteproc0/firmware $ echo start >/sys/class/remoteproc/remoteproc0/state   Once done we can verify that the M33 firmware is running on DDR Hope everyone finds this useful! For any question regarding this document, please create a community thread and tag me if needed. Saludos/Regards, Aldo.

Change ambient graphic - Ambient Grafic:      Fluxbox (low memory and fast initialization) - Install (root):      apt-get update      apt-get install fluxbox - After instalation, edit file /etc/lightdm/lightdm.conf and change line:      "greeter-session=unity-grreter"  for  "greeter-session=fluxbox"   if, preference auto login comment this line:      "autologin-user=user"  for  "#autologin-user=user" - Reboot and try fluxbox  🙂

When using Gigabit Ethernet on boards i.MX running Windows 10 IoT Core users may experience network unstability and low latency using build W1809_1_1_0_imx-iotcore. This was fixed by increasing the size of Rx/Tx buffer in ethernet driver. Fix will be part of the next release of BSP, to apply fix to current version a patch was created. To apply patch, copy content of zip archive to appropriate location in folder structure and rebuild BSP.

Platform: i.MX8MP EVK L6.6.52 , SDK2.16 The rpmsg_lite_pingpong_rtos demo in SDK will complete 100 times ping-pong and then destory the rpmsg connection and related resources. For Linux kernel, there is no such rpmsg api to finish similiar thing,  which will case imx-rproc imx8mp-cm7: imx_rproc_kick: failed (0, err:-62) , this error indicates that the remoteproc is still try to kick up M7 after rpmsg_lite_pingpong_rtos destory the rpmsg resources.   Here is a simple workaround for this error. 1. drivers/rpmsg/imx_rpmsg_pingpong.c Destory ept when saying goodbye. 2.drivers/rpmsg/virtio_rpmsg_bus.c Disable virtuequeue callback(->imx_rproc_kick) in _rpmsg_destory_ept.   Result: No imx-rproc imx8mp-cm7: imx_rproc_kick: failed (0, err:-62) after 100 times ping-pong    

It is often not easy to use company network to flash application, due to network security (proxy, etc...). We will see in this tutorial, how to flash a Linux application in a SD card with ONLY a SD card reader and simple standard Linux commands. SD card Memory Map A Linux application is divided in 3 parts: the bootloader the Linux Kernel the Linux Rootfs We will flash sequentially these 3 parts Flashing U-boot With the SD card Reader, we will flash the yellow part. In the [...]/ltib/rootfs/boot/ folder $ sudo dd if=u-boot.bin of=/dev/sdb bs=512 skip=2 seek=2 && sudo sync Flashing Linux Kernel With the SD card reader, we will flash the green part. Keep in mind that 1MB=1048576B -> Kernel Offset. $ sudo dd if=uImage of=/dev/sdb bs=1048576 seek=1 && sudo sync Configure U-boot variables To launch the Kernel, you need to configure U-boot. Plug the serial cable on the EVK: 115kbps, 8 bits, 1 stop and no parity EVK switches must be configured as below: DS1 DS2 DS3 DS4 DS5 DS5 DS7 DS8 DS9 DS10 Boot from SD/MMC Card 0 0 0 0 0 0 1 1 0 0 Put the SD card in the EVK (bottom slot) and launch the app. In the hyperterminal type:   BBG U-Boot > printenv To print environnement variables Modify the bootcmd: BBG U-Boot > setenv bootcmd_mmc 'run bootargs_base bootargs_mmc;mmc read 0 ${loadaddr} 0x800 0x1800;bootm' "0x1800" is the size of the kernel. Must be bigger than uImage Kernel file (0x1800x512Byte=3MB) If you want to use the WVGA as display screen (kernel need to be configured with CLAA support), for LTIB1007 and after (before it was 'wvga' option): Script for LTIB1007's u-boot on i.MX51 EVK (copy/paste in the hyperterminal): setenv bootcmd_mmc 'run bootargs_base bootargs_mmc; mmc read 0 ${loadaddr} 800 1800 ; bootm' setenv bootargs_mmc 'setenv bootargs ${bootargs} root=/dev/mmcblk0p1 rootwait rw  init=/init' setenv bootargs_base' setenv bootargs console=ttymxc0,115200 di1_primary console=tty1' setenv bootcmd 'run bootcmd_mmc' saveenv Script for LTIB1007's u-boot on i.MX53 EVK (copy/paste in the hyperterminal): setenv bootcmd_mmc 'run bootargs_base bootargs_mmc; mmc read 0 ${loadaddr} 800 1800 ; bootm' setenv bootargs_mmc 'setenv bootargs ${bootargs} root=/dev/mmcblk0p1 rootwait rw  init=/init' setenv bootargs_base 'setenv bootargs console=ttymxc0,115200 di0_primary console=tty1' setenv bootcmd 'run bootcmd_mmc' saveenv You must have the following printenv: BBG U-Boot > printenv bootdelay=3 baudrate=115200 loadaddr=0x90800000 netdev=eth0 ethprime=FEC0 uboot_addr=0xa0000000 uboot=u-boot.bin kernel=uImage bootargs_nfs=setenv bootargs ${bootargs} root=/dev/nfs ip=dhcp nfsroot=${serveri p}:${nfsroot},v3,tcp bootcmd_net=run bootargs_base bootargs_nfs; tftpboot ${loadaddr} ${kernel}; boot m load_uboot=tftpboot ${loadaddr} ${uboot} ethact=FEC0 bootargs=console=ttymxc0,115200 di1_primary root=/dev/mmcblk0p1 rootwait rw init =/init bootcmd_mmc=run bootargs_base bootargs_mmc; mmc read 0 ${loadaddr} 800 1800 ; bo otm bootargs_mmc=setenv bootargs ${bootargs} root=/dev/mmcblk0p1 rootwait rw init=/i nit bootargs_base=setenv bootargs console=ttymxc0,115200 di1_primary bootcmd=run bootcmd_mmc stdin=serial stdout=serial stderr=serial</br> Environment size: 748/131068 bytes BBG U-Boot > Create ext3 partition With the SD card reader, create an ext3 partition. You can use gparted, a graphical partition manager tool. Launch gparted: $ sudo gparted Create a new ext3 partition, with 20MB of offset: Copying Linux To copy rootfs folder generated by LTIB, type in the shell: $ sudo cp -r /[…]/ltib/rootfs/* /media/FreescaleSD/ && sudo sync Test application Put the SD in the slot slot and launch the application. Password is root.

Below is one implementation of i.MX as a USB Playback/Capture device on one OTG port. Design Block Diagram: Driver user space interface: As file /dev/gadget/g_audio file system : gadgetaudiofs_type usage: mount -t gadgetaudiofs path /dev/gadget /* if /dev/gadget is not exist, create it manually */ r/w interface open read write close ssize_t read(int fd, void *buf, size_t count); Notice: Attempts to read up to count bytes from file descriptor fd into the buffer starting at buf. On success, the number of bytes read is returned. This call may be blocked if device can't give enough data. Only if usb out pipe be broken(host stop audio player), return value is still positive and less than count. Error: Count must align with PCM audio frame size. If not -EFAULT as errorno. Notes: Audio frame size = audio sample size x audio channels. ssize_t write(int fd, void *buf, size_t count); Notice: Writes up to count bytes from the buffer pointed buf to the file referred to by the file descriptor fd. On success, the number of bytes written is returned. This call will never be blocked, even if the internal ring buffer dose not have enough space to write. A successful return from write() that return value equal to count does not make any guarantee that data all have been put to internal ring buffer. For example, if ring buffer is empty and has 1K bytes space, while write count is 3K bytes, only the last 1K bytes will be put to the ring buffer! Key attribute for g_audio driver USB out pipe parameter: Sample width hard code to 16bits. static int out_sample_rate = 48000; static int out_channel = 2; #define OUT_EP_ALIGN (2 * out_channel) // 2 mean 2 bytes, sample width 16bits OUT_EP_ALIGN mean “read ring buffer” write/read align, if read/write length not align this value, throw out error. Read mean user space read system call, write mean driver internal copy req->buf to “read ring buffer”. #define OUT_EP_MAX_PACKET_SIZE (192) // out pipe max packet size, it based on out_sample_rate and out_channel. 192 = (48KHZ / 1000) * out_channel * sample_width(as bytes) 192 = (48000 / 1000 ) * 2 * 2; Hear 1000 based on: as_out_ep_desc.bInterval = 4; /* 4 in hi speed as 2 exp (4 -1) = 8 uframe time, 8 uframe time is 8 * 125 us = 1ms 1000 = 1s / 1ms */ static int out_req_count = 256; /* out pipe queue count, this value dose not introduce extra audio latency ! */ #define AUDIO_READ_RINGBUF_LEN (23 * OUT_EP_MAX_PACKET_SIZE) /* 4416 bytes, max valid 23 * 192, about 23 ms at 48KHZ, this value determine out pipe max audio latency */ If “read ring buffer” full, how to handle continue write: discard the 1/3 oldest ring buffer. See function int f_audio_ringbuffer_write   if(ringbuf->len - ringbuf->actual < alignLen)   {   ringbuf->rp += (alignLen * (ringbuf->len /(alignLen * 3))); /* if cache up read pointer, discard 1/3 ring buf */   ...   } USB in pipe parameter: Sample width hard code to 16bits. static int in_sample_rate = 8000; static int in_channel = 2; #define IN_EP_ALIGN (2 * in_channel) // 2 mean 2 bytes, sample width 16bits IN_EP_ALIGN mean “write ring buffer” write/read align, if read/write length not align this value, throw out error. Write mean user space write system call, read mean driver internal copy “write ring buffer” to req->buf. #define IN_EP_MAX_PACKET_SIZE (32) // in pipe max packet size, it based on in_sample_rate and in_channel. 32 = (8KHZ / 1000) * in_channel * sample_width(as bytes) 32 = (8000 / 1000 ) * 2 * 2; Hear 1000 based on: as_in_ep_desc.bInterval = 4; /* 4 in hi speed as 2 exp (4 -1) = 8 uframe time, 8 uframe time is 8 * 125 us = 1ms 1000 = 1s / 1ms */ static int in_req_count = 32; /* in pipe queue count, this value dose introduce extra audio latency ! Latency = 32ms */ #define AUDIO_WRITE_RINGBUF_LEN (32 * OUT_EP_MAX_PACKET_SIZE) /* 1024 bytes, max valid 32 * 32, about 32 ms at 8KHZ, this value and in_req_count determine in pipe max audio latency 32 + 32 = 64 ms*/ If “write ring buffer” full, how to handle continue write: discard the 1/3 oldest ring buffer. See function int f_audio_ringbuffer_write   if(ringbuf->len - ringbuf->actual < alignLen)   {   ringbuf->rp += (alignLen * (ringbuf->len /(alignLen * 3))); /* if cache up read pointer, discard 1/3 ring buf */   ...   } Test Environment. Ubuntu 10.0.4 LTS Kernel 3.0.0-15 64bit. Ubuntu 10.0.4 LTS Kernel 2.6.32-42 64bit. Test application. Test user space application based on http://www.rosoo.net/a/201107/14725.html I will attach modified code. Test procedure. /* I.MX28 EVK board audio ADC default input is MIC, so, set it to LINE IN */ amixer sset 'ADC Mux' 'LINE_IN'  /* insmod g_audio driver and create directory for gadgetaudiofs */ modprobe g_audio && mkdir /dev/gadget /* mount gadgetaudiofs */ mount -t gadgetaudiofs path /dev/gadget /* start read g_audio device application.   It read PCM data from g_audio_device and put it to alsa playback device.   It read from g_audio_device per read system call per period_size (300 bytes).   See alsa PCM playback configuration   stream : PLAYBACK access : RW_INTERLEAVED   format : S16_LE   subformat : STD   channels : 2   rate : 48000   exact rate : 48000 (48000/1)   msbits : 16   buffer_size : 1200 (frames) (buffer time is 1200 / 48000 = 25ms)   period_size : 300 (frames)   period_time : 6250 (ns) */ ./lplay /dev/gadget/g_audio /* start write g_audio device application. It read PCM data from alsa capture device and put it to g_audio_device. It write to g_audio_device per write system call per period_size (50 bytes). See alsa PCM capture configuration   stream : CAPTURE   access : RW_INTERLEAVED   format : S16_LE   subformat : STD   channels : 2   rate : 8000   exact rate : 8000 (8000/1)   msbits : 16   buffer_size : 200 (frames) (buffer time is 200 / 8000 = 25ms)   period_size : 50 (frames)   period_time : 6250 (ns) */ ./lrecord /dev/gadget/g_audio The two processes CPU utilization on I.MX28 EVK board is about 5~15%, if you change per g_audio_device read/write system call size more larger, the more smaller CPU utilization you will get, but at the same time the more audio latency you will get. Per read/write system call size should has relation will “read/write ring buffer” size in g_audio driver. For example, if per write system call size is larger than “write ring buffer” size, then every write system call will discard some part of write buffer data. During 15 hours lplay and lrecord long test, driver and application both use default configuration as upper description, summarily 271 times driver internal buffer full appear. In another test, driver keep default configuration, new test set microphone ALSA capture buffer to 250ms, ALSA capture read as unblock mode, other configuration as lrecord application, block read USB gadget device 200 x 192 bytes (waiting 200ms), then unblock read whole ALSA capture buffer, found about every 1.5s, ALSA buffer will less then 16bytes (4 sample) compare to 200 x 32 bytes. Clock Sync issue of echo cancellation based on this implementation: Note： USB clock domain different with play back and microphone, some buffer will be discard by USB audio driver. See this diagram: 1: Echo cancellation application will try best to read “USB Output Buffer”, so no buffer will be discarded from output. ( Application input and output based on the same clock). 2: “Host playback buffer” maybe overrun because:   A: Playback source unstable and host playback buffer not enough larger.   B: Clock(playback) quick than Clock(USB). 3: Echo cancellation application will try best to read “ALSA Buffer”, so no buffer will be discarded from “ALSA buffer”. (Application discard some samples of “ALSA Buffer”) 3: Echo cancellation application handle “USB Output Buffer” and “ALSA Buffer” based on “USB Output Buffer” that same time mean based on Clock(USB). We assume Echo cancellation application will insert or discard some samples of “ALSA Buffer” based on “USB Output Buffer”. 4: Echo cancellation application will send processed buffer to USB audio driver based on Clock(USB), so no buffer will be discard from “USB Input Buffer”. If Echo cancellation application said “ I don't have the ability to insert or discard some samples of “ALSA Buffer”, we need adjust the Clock(MIC) based the internal buffer level of Echo cancellation application. But I think the “internal buffer level” will be influenced by difference of the clocks, the buffer input and output task runtime loading, so it may not be reality to implement this, need do more test on this! Add USB get output/input buffer length interface Add USB SAIF(only for i.mx 28) set clock interface For i.MX28 SAIF clock based on 480MHz. The fraction divider is 16bit, that mean the mini step is 0x 0.0001. 0x 0.0001 * 480MHz = 7324.21875Hz. If master clock as 512x frame rate, the mini step of frame rate is 14.3Hz USB get output/input buffer length interface: IOCTL CMD: #define USBAUDIO_BUFFER_STATUS_GET \ _IOR('g', 200, struct usbaudio_buffer_status) structure: struct usbaudio_buffer_status{   /* all as bytes */   __u32 playbackBufferTotalLen;   __u32 playbackBufferCurrentLen;   __u32 microphoneBufferTotalLen;   __u32 microphoneBufferCurrentLen; }; usage: struct usbaudio_buffer_status bufferStatus; ioctl(fd, USBAUDIO_BUFFER_STATUS_GET, &bufferStatus); USB SAIF(only for i.mx 28) set clock interface. IOCTL CMD: #define USBAUDIO_SAIF_CLOCK_CONTROL \ _IOWR('g', 201, struct usbaudio_saif_clock_control) structure: struct usbaudio_saif_clock_control{   /* all as HZ -1 as invalid */   __u32 saifCurrentClock; /* read */   __u32 saifNextClock; /* write */ }; usage: struct usbaudio_saif_clock_control saifClkCtl; saifClkCtl.saifNextClock = -1; ioctl(fd, USBAUDIO_SAIF_CLOCK_CONTROL, &saifClkCtl); saifClkCtl.saifNextClock = saifClkCtl.saifCurrentClock + step; ioctl(fd, USBAUDIO_SAIF_CLOCK_CONTROL, &saifClkCtl); Compile sample: /opt/freescale/usr/local/gcc-4.4.4-glibc-2.11.1-multilib-1.0/arm-fsl-linux-gnueabi/bin/arm-linux-gcc -I /home/haidong/Work/Mx28/L2.6.35_10.12.01_ER_source/LTIB/ltib/rootfs/usr/include/ -I /home/haidong/Work/Mx28/L2.6.35_10.12.01_ER_source/LTIB/Kernel/linux-2.6.35.3/include -L /home/haidong/Work/Mx28/L2.6.35_10.12.01_ER_source/LTIB/ltib/rootfs/usr/lib/ lrecord.c -o lrecord -lasound

Update 2 Nov 2016: The work begun with this current sensor board has been superseded by this 4-channel solution. The ribbon cables used below, although easier to solder, were very stiff and tended to lift the sensors off the double sticky foam tape, which endangered the target application board. This post remains for historical purposes. This little board set was put together quickly to measure run current as well as sleep current. The sensor board is intended to be affixed with double sided tape to the board under test. A flat ribbon cable connects to the connection board where the power and current sensor connections may be made. The holes accommodate banana jacks. The current range is selected via the dip switch on the connection board. Below is an image of the schematic. The attached PDF contains the schematic, layout and partial Digikey parts lists along with embedded source files (look for the thumb-tacks).   The DMN1019USN FETs have a Vgs of 8V, which limits the maximum current which may be measured (currents above will starve the output of the current sensor amplifiers since the output cannot swing high enough). With a supply of ~7.5V, a maximum high current of ~3A is possible with the 2V/A gain (A4) version of the INA250. With a 2 Ohm shunt for the low current range, the maximum current with an INA212 (1000V/V gain) is ~3mA. Two FETs in parallel were used to decrease the series resistance when shorting the low current shunt. [NOTE: The voltage applied to the gates of the FETs assumes that the ground on the both board under test and the current sense board combo are in common.  An isolated supply could have been used but was not for simplicity.] The high current range is intended for normal operation, i.e., measuring run currents.The low current range should only be selected once the board is configured for a low power mode. Once in that mode, the low power mode may be selected.  To use an instrumented target board without having to have the connection board hooked up and powered, jump the two vias (spaced 0.1", labeled "Jump" by the current input connections). These vias short the 2 Ohm low current shunt resistor. The target board is connected via the 3-pin header. The outer two points are the negative input connection; the center is the positive. Two negative connections are provided to avoid having to cross the connection wires. These wires should be kept as short as possible. The series resistance at the input in the high range (dip switch off) was under 25mOhms, so the connections wires only add to that. The board set may be used as-is before snapping apart since connections between the boars runs through the row of snap-vias. A ribbon cable needs be used after snapping them apart. Finer pitch ribbon could have been used but it'd be much less friendly for hand soldering. Board sets in multiples of 3 may be ordered here. Here are some photos of the prototype board (some silk screen errors and the banana jack holes were drilled too small). Before snapping apart on the left and after with the ribbon cable and connectors added on the right. Here is a photo of the i.MX6SL on the EVK instrumented for low-power sleep-mode current measurement on VDD_HIGH_IN: SENSOR CALIBRATION CHECK: The calibration of three sensor boards was checked by forcing an accurate, known current with a Keysight B2902A Source Measure Unit (SMU). The average sensor output was measured for each forced current in the high and low range. The data was plotted and best fit lines were applied: The data for each sensor was very linear. The coefficients and offsets of all 6 best fit lines were very similar as can be seen above. The data can be perused in the attached Excel file (HiLo-sensors-1-3-calib.xlsx). The three sets of coefficients for the high range sensor (the INA250A4) were averaged. For each sensor's output, the current was calculated using these averaged coefficients and tabulated next to the forced current (the brown data). All of the calculated currents were within at most 20mA of the actual current forced by the SMU. TO DO: Two outputs are somewhat cumbersome; it'd be handier to just switch which sensor is outputting to the measurement device. It'd also be really handy to have a 4 channel distribution board and 4 sensor boards, which would allow the use of a 4 channel oscilloscope. Some LEDs on the distribution board indicating which measurement range is in use would also be nice... UPDATE 7 OCT 2016: Working now on a Kinetis-based, data-logging capable, 4-channel power profiler for run and sleep. The Kinetis ADCs will be used to measure the sensor outputs and power supply rail voltages, which should be fine given the level of accuracy that is required. Data is sent up the line in real time via a USB serial port, which opens the possibility of the target board profiling it's own power consumption, including low power modes (a wake-up line for the target board is provided for just that purpose). For more information on current measurements in general, see this tutorial series: A Current Sensing Tutorial--Part 1: Fundamentals | EE Times  A Current Sensing Tutorial-Part II: Devices | EE Times  A Current Sensing Tutorial--Part III: Accuracy | EE Times  A Current Sensing Tutorial-Part IV: Layout and Troubleshooting Guidelines | EE Times