i.MX Processors Knowledge Base

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX Processors Knowledge Base

Discussions

Sort by:
Hi,          Here is the document about how to enable spread spectrum in imx6.   best regards Jack
View full article
Overview In this doc, I will try to give you a brief of the Linux kernel changes between 4.x and 5.4 (5.0/5.1/5.2/5.3/5.4), which related to i.MX users/developers: Important bug fix and improvements according to my experiences New features you should keep an eye on Interfaces changes may impact applications i.MX up-streaming I cannot make sure every single change's description is 100% correct. Either, I cannot list all of the impacts to the i.MX platform due to my limited knowledge and experiences. I hope this doc can help you on developing kernel drivers, user applications or debugging issues of 5.x i.MX kernel release. Changes Subsystem/Modules Detail changes Comments References Kernel Cores binder: new binderfs, a pseudo-filesystem for the Android Binder IPC driver which can be mounted per-ipc namespace allowing to run multiple instances of Android Hmm... that may imply we can run multi-instance Android without Hypervisor? sysctl: add panic_print sysctl to configure which information to print at panic time, w/ replay option So we can define the panic information for better debugging the crash issue. Also option for users to configure the "panic_print" to replay all dmesg in buffer, some of which they may have never seen due to the loglevel setting, which will help panic debugging How to use boot: Add boot option ( driver_async_probe=... ) to specify drivers to be async probed Asynchronous driver probing can help much on kernel fastboot, and this option can provide a flexible way to optimize and quickly verify async driver probe. Asynchronous device/driver probing support [LWN.net]  swiotlb: add debugfs to track swiotlb buffer usage The device driver will not be able to do dma operations once swiotlb buffer is full, either because the driver is using so many IO TLB blocks inflight, or because there is memory leak issue in device driver. Export buffer usage in debugfs can help. Please note, almost all of the dma buffers on i.MX8 platform comes from swiotlb. aarch64 Linux Kernel Memory Management  New mount syscall API The kernel supports a wide variety of filesystem types, and each has its own, often extensive set of options. As a result, the mount() system call is complex. This makes application code who need mount FS more clear. Six (or seven) new system calls for filesystem mounting [LWN.net]  New APIs to support pidfs clone return pidfs, new syscall pidfd_send_signal(2), which uses file descriptors from /proc/<pid> as stable handles on struct pid.  Toward race-free process signaling [LWN.net]  locking: rwsem improvement unification and simpler micro-optimizations, performance improvement of this locking primitive. Preparations for PREEMPT_RT It's excited that community decided to merge the PREEMPT_RT kernel changes into mainline. It's well known as rt-patch for hard real-time use cases like industry. Index of /pub/linux/kernel/projects/rt/  Memory management KASAN: Improved the KASAN performance for arm64 KernelAddressSANitizer (KASAN) is a dynamic memory error detector. It provides a fast and comprehensive solution for finding use-after-free and out-of-bounds bugs. It's useful when debugging kernel drivers and modules memory issue. The Kernel Address Sanitizer (KASAN) — The Linux Kernel documentation  Fragmentation avoidance improvements, reducing fragmentation events by over 90%. With this change, the page allocator would spread allocations across zones before introducing fragmentation.  We can always found customer's product memory fragment in some use cases in old kernel. Which would cause kmalloc or cma alloc failure and system stop. Balance between zones (i.MX8 we have DMA/NORMAL zones) to avoid fragment is very helpful. patch intro One of customer case(fixed by not using kmalloc): https://jira.sw.nxp.com/browse/MLK-23220  Increase success rates and reduce latency of compaction (physical memory defragmentation) Memory compaction is the way to avoid memory fragment. Memory compaction [LWN.net]  Improve Out Of Memory (OOM) reports, include victim's memcg More clear kernel OOM report may help lot Remove the ancient OOM killer heuristic that preferred to kill children of the "worst" process rather than the process itself Improve the OOM efficiency zram improvements, which can help estimate wasted memory, and perform writeback that will free it zram is actually used very widely in the Android system as backup swap for physical memory. Swap performance is very important. Low RAM Configuration  |  Android Open Source Project  Simplify some of the early memory allocations by replacing usage of older memblock APIs with newer and shinier ones memblock API changes. If you used memblock in your drivers, then need to check. Boot time memory management — The Linux Kernel documentation  psi: Improves the Pressure Stall Information resource monitoring With this mechanism, Android can monitor for, and ward off, mounting memory shortages before they cause problems for the user. For example, using memory stall, monitors in userspace like the low memory killer daemon (lmkd) can detect mounting pressure and kill less important processes. Supported in Android10, replace the vmpressure. Low Memory Killer Daemon (lmkd)  |  Android Open Source Project  Pressure stall monitors [LWN.net]  Improve vmap allocation Speed up the vmalloc https://lkml.org/lkml/2018/10/19/786  Introduce madvise() flags MADV_COLD, MADV_FREE, MADV_PAGEOUT MADV_COLD marks pages as inactive (thus more easily reclaimed under memory pressure), but doesn't discard the contents like MADV_FREE does, and MADV_PAGEOUT , which reclaims pages immediately. Android would use this flags for better memory management kernel/git/torvalds/linux.git - Linux kernel source tree  memcg: from v1->v2 shrink all memcg caches for the slab cache Throttle allocators when reclaim cannot keep up with v2 memory.high limit Introduce gradual reclaim pressure..... Control Group v2 — The Linux Kernel documentation  Block layer Boot to a device-mapper device without initramfs DM is widely used, you can not bootup to DM rootfs directly. Android 10 would use dynamic partition by creating super partition for /system, /vendor of dm-linear Implementing Dynamic Partitions  |  Android Open Source Project  Tracing and Perf Perf: lots of improvement TBD Security security: Create "kernel hardening" config area Help mitigate kernel vulnerabilities and find bugs in kernel drivers, like Stack buffer overflow mitigation, Hardened usercopy Kernel Hardening  |  Android Open Source Project  LSM: Add kernel lockdown functionality When enabled, the new "lockdown" feature will restrict some kernel functionality, even for the root user, making it harder for compromised root accounts to compromise the rest of the OS Kernel lockdown in 4.17? [LWN.net]  Networking Enable MSG_ZEROCOPY for udp sockets Improve the UDP sending performance. Pay attention that the zero copy UDP sockets only limit to the send operations, not receive. Also require application code change, not efficient at small MTU. Zero-copy networking [LWN.net]  ARM/ARM64 New SoCs: i.MX7ULP with EVK i.MX8MQ with EVK i.MX8MM  i.MX8QXP perf vendor events: Add Cortex-A57 and Cortex-A72 events  support all ARMv8 recommended events Make CONFIG_ZONE_DMA32 configurable commit Which means you can remove the DMA zone, and use only one single normal zone in kernel. Drivers drm: Initial merge of timeline sync objects Timeline syncobj gives user more flexibility and convenience to do sychronization. Android does not used. Staging driver: i.MX7 MIPI CSI subdev NXP QuadSPI driver Introduce Sound Open Firmware (SOF) for audio DSP devices Big changes to the current HiFi4 DSP (in i.MX8QM/QXP) infrastructure. The SOF is an open source audio DSP firmware and SDK that provides audio firmware infrastructure and development tools. Also integrated with current kernel alsa subsystem.  Home - Sound Open Firmware  Firmware - AlsaProject  How to build i.MX8 HiFi4 firmware Add NXP SJA1105 DSA network driver with ptp support Used for networking switch Add TJA11xx PHY driver Add lpspi driver support fsl_lpuart: add imx8qxp support Add SCU watchdog/RTC support regmap: add i3c bus support commit Means we can have i3c bus support in regmap now. References Linux_Kernel_Newbies - Linux Kernel Newbies  Welcome to LWN.net [LWN.net]  kernel/git/torvalds/linux.git - Linux kernel source tree 
View full article
恩智浦BSP的内核定制 ........................................... 103 6.1 IO管脚配置与Pinctrl驱动 .................................... 103 6.2 新板bringup ........................................................ 118 6.3 更改调试串口: .................................................. 127 6.4 uSDHC设备定制(eMMC flash,SDcard, SDIOcard) 133 6.5 LVDS LCD 驱动定制 .......................................... 142 6.6 GPIO_Key 驱动定制 .......................................... 145 6.7 GPIO_LED 驱动定制 ......................................... 149 6.8 Fuse nvram驱动 ................................................. 152 6.9 SPI与SPI Slave驱动 ........................................... 153 6.10 USB 3.0 TypeC 改成 USB 3.0 TypeA(未验证) ... 160 6.11 汽车级以太网驱动定制 ....................................... 160
View full article
NOTES: Empty cells do not mean there is no bitbake parameter for the corresponding ltib one. This is still work in progress. Both engines are completely different and doing a one-to-one comparison is not actually fair. The following tables compare the two core build tools, ltib for LTIB and bitbake for the Yocto Project (YP, hereafter). For YP, there is another important tool called HOB,  when appropriate, we add comments on the Comment's column. There are two main tables, 'ltib modes versus bitbake' 'ltib options versus bitbake'.          We split in two based how ltib splits its parameter, so the order is the same as the one shown when typing './ltib --help'. LTIB comes in every released BSP, follow the User Guide to install it. The command 'ltib' is a script located on the folder with the same name, so all ltib commands should be run with './' as prefix YP can be seen of a series of layers (folders). To download these, including the Freescale layers, follow this link. The command 'bitbake' must be installed independently, you can either use the package manager of you OS (e.g. sudo apt-get install bitbake on Ubuntu) or download the source code and do the setup manually. Both ways should place the bitbake script into a executable path. ltib modes versus bitbake Mode description ltib command bitbake command Comment Just prep the package ltib -m prep -p <package> bitbake <package> -c patch With bitbake when running the patch task, it executes two lower tasks: fetch and unpack. For example, if one wants a untouched (no yocto patches) kernel, one can try: 'bitbake linux-imx -c unpack' and code unpacked code is placed on tmp/work/imx6qsabresd-poky-linux-gnueabi/linux-imx/<version>/git/ rpmbuild -bc --short-circuit ltib -m scbuild -p <package> bitbake <package> -c compile With bitbake running compile also runs a lower task: configure. rpmbuild -bi --short-circuit ltib -m scinstall -p <package> bitbake <package> -c With ltib the install task executes the %Install section of the package's spec. With bitbake the same task executes all related package's recipe install functions, e.g. do_install. Note: with ltib running a higher task (like scinstall) will not execute lower tasks (like scbuild and prep); this is not the case for bitbake: it runs lower tasks automatically. does an scinstall followed by an install to the rootfs ltib -m scdeploy -p <package> bitbake <package> -c build With bitbake, build is the default task, so one can even omit the -c build parameter, e.g. 'bitbake <package>' generate and merge a patch (requires -p <pkg>) ltib -m patchmerge -p <package> NA This is a pretty nice feature from LTIB, unfortunately with bitbake the command does not exit. For example, to patch the Kernel's recipe, take a look at this procedure. In case you follow all these steps to fix a bug, do not forget to send your patch to the community. lean/uninstall target packages ltib -m clean -p <package> NA With bitbake the 'clean' counterpart does not exit. If one needs to remove a specific package from a build, you may remove it from the image configuration file (e.g. file meta-fsl-demos/recipes-fsl/images/fsl-image-gui.bb, remove item on IMAGE_INSTALL variable); if package is inside a package group (e.g. ./meta-fsl-demos/recipes-fsl/packagegroup/packagegroup-fsl.bb) you may remove it there. After this change, bitbake again and the resulting image won't have the package. With HOB, this is much simpler due to its Graphical User Interface. Just type hob on your build directory, select the machine and the base image, then click on the 'Edit Image'. On that window you can easily deselect packages. Once deselection is done, build the image. full cleanup, removes nearly everything ltib -m distclean NA With bitbake the 'distclean' command does not exit. The way to remove all the built, remove the build/tmp folder. Be careful, next time you run bitbake, all tasks for all packages will be executed, in other words, you will start from scratch. list packages (alphanumeric) ltib -m listpkgs non-GUI: bitbake -g fsl-image-gui && cat pn-depends.dot GUI: bitbake -g -u depexp fsl-image-gui A bit more complex non-GUI: bitbake -g <image> && cat pn-depends.dot | grep -v -e '-native' | grep -v digraph | grep -v -e '-image' | awk '{print $1}' | sort | uniq list package names and licenses ltib -m listpkgseula NA With HOB, you can see every package name name and its licence. Just type hob, then select the machine and image, and click on the 'Edit Image' button. On the 'All recipes' tab, you get a list of packages with their licenses. list packages in twiki format ltib -m listpkgstw NA list packages in a format for import into spreadsheet ltib -m listpkgscsv NA make a binary release iso image ltib -m release NA make a non-distributable test iso release ltib -m trelease NA configure selected platform (no build) ltib -m config NA There is no way to open a configuration menu with bitbake. Instead, you can use hob. With hob, things are much easier. Just type hob under the build folder and you can select the machine and the image. If the image you want does not fit to the ones already available, you can add packages manually and even store your new tuned image. NOTES: 1. On YP, an image is a similar concept as LTIB's package profile (usually called just profile). There are many predefined images which can be used as starting point, so type 'bitbake <image name>'. 2. In case the kernel needs to be configure, run 'bitbake linux-imx -c menuconfig'. sub-platform selection (no build) ltib -m selectype NA The selectype on LTIB opens two menus: 1. Platform and the Package Profile selection 2. Configuration menu (the same menu as the one shown with -m config). In case one needs to do execute just the first task, just run 'bitbake <image name>'. In case you need to execute both, run hob. enter ltib shell mode (sets up spoofing etc) ltib -m shell bitbake <package name> -c devshell import srpms into ltib (semi-automatic) ltib -m addsrpms ltib options versus bitbake Option Description ltib command bitbake command Comments Root context number (0 is the primary and implicit) ltib --rootn | ltib -R operate on this package only ltib --pkg | ltib -p bitbake <package> With bitbake there is no need to add a '-' parameter, just use the package name without the .bb extension run the interactive configuration and build ltib --configure  | ltib -c NA See the mode -m config for more info run the sub-platform configuration and build ltib --selectype NA See the mode -m selectype for more info configuration file to build from (defaults to .config) ltib --preconfig bitbake <predefined image> With bitbake use any of the predefined images (assuming that these have not been modified), e.g. bitbake core-image-minimal or bitbake fsl-image-gui (it happens to be the smallest and the largest image, in terms of number of packages) profile file.  This is used to select an alternate  set of userspace packages, this is saved and used on later runs of ltib (e.g config/profiles/max.config) ltib --profile use this resource file ltib --rcfile <f> | ltib - r <f> batch mode, assume yes to all questions ltib --batch | ltib -b force rebuilds even if they are up to date ltib --force | ltib -f bitbake --force | bitbake -f For example, to force recompiling the kernel: bitbake linux-imx -c compile -f re-install rpms (but don't force rebuild) ltib --reinstall | ltib -e bitbake <package name> -c install -f remove (erase) rpm ltib --erase | ltib -E turn off install/uninstall dependency checks ltib --nodeps | ltib -n bitbake -b <somepath/somefile.bb> For example, to build just the kernel (no dependencies, just kernel): bitbake -b ../sources/meta-fsl-arm/recipes-kernel/linux/linux-imx_3.0.35.bb NOTE: ALL dependencies should be already be installed, otherwise the command will fail don't force install rpms that have file conflicts ltib --conflicts | ltib -k keep the srpms after the build (deleted by default) ltib --keepsrpms | ltib -s more output ltib --verbose | ltib -v bitbake --verbose | bitbake -v On YP, the log can be too verbose, so one way to handle the amount of log is to store it and then grep it: bitbake linux-imx | tee log; grep -i <your string to seach> < log mostly a dry run (calls to system are just echos) ltib --dry-run | ltib -d bitbake --dry-run | bitbake -n try to continue on package build errors (autobuilds) ltib --continue | ltib -C bitbake --continue | bitbake -k print the application version and quit ltib --version | ltib -V bitbake --version do not redirect any output ltib --noredir | ltib -N run the deploy scripts even if build is up to date ltib --deploy | ltib -D bitbake <image name> -f disabled deployment (even with -p <pkg>) ltib --no-deploy just download the packages only ltib --dlonly bitbake -c fetchall <image name> E.g. bitbake -c fetchall core-image-minimal test that the BSP's packages are available ltib --dltest check against external staging repositories ltib --external leave the sources unpacked (only valid for pkg mode) ltib --leavesrc | ltib -l NA This is the default mode in YP. All source code can be found on tmp/work. In case you want to remove source code after building (as in LTIB), add INHERIT += "rm_work" to your local.conf. NOTE: If your adding changes to a particular package, these will be lost. In case you want to keep source code of a specific package, include this on the RM_WORK_EXCLUDE variable (e.g. RM_WORK_EXCLUDE += "busybox eglibc"). Make the selected root number sticky --sticky Remove root stickiness --no-sticky (re)configure/build/install the host support package set --hostcf use with package listings --enable use if you really want to ignore any locks (careful!) --ignorelock used with -m release to copy additional content --fullbsp used with -m release to copy specical packages into ISO --distmap don't check sudo, work around for broken sudo (fc9) --no-sudo use git for some package's build where use-git-mode is either: internal    Use fsl internal git external   Use fsl external git --use-git-mode use external git for some package's build --external-git help on usage --help | -h --help | -h
View full article
Hello everyone, this document will explain on how to use the UUU (Universal Update Utility) tool to flash Linux to an i.MX device (i.MX 8MM).   Requirements:   MX 8M Mini EVK UUU tool documentation, available here Linux Binary Demo Files - i.MX 8MMini EVK UUU 1.2.135 binary Serial console emulator (tera term or putty)   UUU auto script For this example is used the L4.14.98_2.0.0_ga demo image for the i.MX 8MM, inside the demo image we will find the auto script, which by default flash the eMMC of the board, the structure of the script is as following   /***********************************************************************************/ uuu_version 1.2.39   # This command will be run when i.MX6/7 i.MX8MM, i.MX8MQ SDP: boot -f imx-boot-imx8mmevk-sd.bin-flash_evk   # This command will be run when ROM support stream mode # i.MX8QXP, i.MX8QM SDPS: boot -f imx-boot-imx8mmevk-sd.bin-flash_evk   # These commands will be run when use SPL and will be skipped if no spl # SDPU will be deprecated. please use SDPV instead of SDPU # { SDPU: delay 1000 SDPU: write -f imx-boot-imx8mmevk-sd.bin-flash_evk -offset 0x57c00 SDPU: jump # }   # These commands will be run when use SPL and will be skipped if no spl # if (SPL support SDPV) # { SDPV: delay 1000 SDPV: write -f imx-boot-imx8mmevk-sd.bin-flash_evk -skipspl SDPV: jump # }   FB: ucmd setenv fastboot_dev mmc FB: ucmd setenv mmcdev ${emmc_dev} FB: ucmd mmc dev ${emmc_dev} FB: flash -raw2sparse all fsl-image-validation-imx-imx8mmevk.sdcard FB: flash bootloader imx-boot-imx8mmevk-sd.bin-flash_evk FB: ucmd if env exists emmc_ack; then ; else setenv emmc_ack 0; fi; FB: ucmd mmc partconf ${emmc_dev} ${emmc_ack} 1 0 FB: done /***********************************************************************************/    In short, when the board goes into serial downloader mode UUU downloads the bootloader to internal RAM, once done and uboot is running, through fastboot utility it will flash .sdcard file and uboot to the eMMC on the board.   More information about the protocol UUU use please refer to the UUU documentation (UUU.pdf) section 5 Supported protocol.   Running the tool In order to run the tool the binary of uuu needs to be downloaded, the binary files can be downloaded from the link above, uuu.exe is for Windows and uuu is for Linux. Once downloaded it can be placed inside the same file as the demo image, this so it is easy to run and cleaner on the shell commands.   Windows In windows OS the tool should be run using the Windows PowerShell in administrator mode, once open we will run the next commands: > .\uuu.exe uuu.auto   Linux >$ sudo ./uuu uuu.auto   The tool will start running and should be waiting for any i.MX device to be detected by host pc   Preparing the board For the board to be flashed it is needed to be in download mode, the switch configuration (i.MX 8MM EVK) is as following: SW1101  -  1010XXXXXX SW1102  -  XXXXXXXXX0   Connect a USB cable from the host pc which will run the tool to the USB OTG/TYPE C port, usually specified as download, on the board.   Connect a USB cable from the host to the OTG-to-UART for console output, usually specified as debug, on the board.   Open terminal emulator program with the following settings: Bits per second - 115200 Data bits - 8 Parity - None Stop bits - 1 Flow control - None   Power on the board, the download will start and the serial prompt will show the progress in uboot, wait until the tool show success.   Finally power off the board and change the switch configuration to boot from the eMMC, power on the board again and it should boot successfully!   Built in scripts One can use the built in scripts using the -b option to burn the bootloader  and the rootfs to the target flash, just type the command accordingly to the target flash device.    SD Write bootloader only: Windows: > .\uuu.exe -b sd <bootloader> Linux: $ sudo ./uuu -b sd <bootloader>   Replace <bootloader> for your .imx/.bin file, example using the i.MX 8MM for Windows and Linux respectively below. > .\uur.exe -b sd imx-boot-imx8mmevk-sd.bin-flash_evk $ sudo ./uuu -b sd imx-boot-imx8mmevk-sd.bin-flash_evk    Write whole Linux image Windows: > .\uuu.exe -b sd_all <bootloader> <rootfs>.sdcard Linux: $ sudo ./uuu -b sd_all <bootloader> <rootfs>.sdcard   Replace <bootloader> and <rootfs> for the name of your .imx/.bin and .sdcard files respectively, example using the i.MX 8MM below. > .\uuu.exe -b sd_all  imx-boot-imx8mmevk-sd.bin-flash_evk fsl-image-validation-imx-imx8mmevk.sdcard $ sudo ./uuu -b sd_all  imx-boot-imx8mmevk-sd.bin-flash_evk fsl-image-validation-imx-imx8mmevk.sdcard   eMMC Write bootloader only Windows: > .\uuu.exe -b emmc <bootloader> Linux: $ sudo ./uuu -b emmc <bootloader>   Example using i.MX 8MM > .\uuu.exe -b emmc imx-boot-imx8mmevk-sd.bin-flash_evk $ sudo ./uuu -b emmc imx-boot-imx8mmevk-sd.bin-flash_evk   Write whole Linux image Windows: > .\uuu.exe -b emmc_all <bootloader> <rootfs>.sdcard Linux: $ sudo ./uuu -b emmc_all <bootloader> <rootfs>.sdcard   Example using i.MX 8MM > .\uuu.exe -b emmc_all imx-boot-imx8mmevk-sd.bin-flash_evk fsl-image-validation-imx-imx8mmevk.sdcard $ sudo ./uuu -b emmc_all imx-boot-imx8mmevk-sd.bin-flash_evk fsl-image-validation-imx-imx8mmevk.sdcard   Hope this will helpful for everyone who is starting to use this flashing tool.
View full article
This patch is for i.MX6 ESPI controller slave mode (SPI timing mode 0 and 3) support. Hardware prepare:   Connect two i.MX6 Sabresd boards, remove U14 SPI nor device, connect two boards like:          MISO --- MISO          MOSI --- MOSI          SS     --- SS          CLK   --- CLK          GND  ---  GND Software prepare: 1>Apply patch spi_slave_2013_10_12.patch on 3.0.35_4.1.0 Linux BSP release.     Note two board all need choose CONFIG_IMX6_SDP_MISCSPI, CONFIG_SPI_SPIDEV of kernel Symbol: IMX6_SDP_MISCSPI [=y]                                                                                                              Location:   |     -> Device Drivers                                                                                                                      |       -> Misc devices (MISC_DEVICES [=y]) Symbol: SPI_SPIDEV [=y]  Location:                                                                                                                                            |     -> Device Drivers                           |       -> SPI support (SPI [=y])    Spi master board choose CONFIG_SPI_IMX_VER_2_3 Symbol: SPI_IMX_VER_2_3 [=y] Location:                                                                                                                                           |     -> Device Drivers                                                                                                                                 |       -> SPI support (SPI [=y])                                                                                                                       |         -> Choose IMX SPI work mode (<choice> [=y])    Spi slave board choose CONFIG_SPI_IMX_VER_2_3_SLAVE. Symbol: SPI_IMX_VER_2_3_SLAVE [=y] Location:                                                                                                                                           |     -> Device Drivers                                                                                                                                 |       -> SPI support (SPI [=y])                                                                                                                       |         -> Choose IMX SPI work mode (<choice> [=y]) 2>Compile test application  mxc_spi_test1.c to generate mxc_spi_test. 3> Test steps : First  spi slave board input cmd mxc-spi-test –D 0 –b 32 –L 32 Then spi master board input cmd mxc-spi-test –D 0 –b 32 –L 32           This tool will write its buffer ( the content is same in two side ) to the  other board  through  SPI bus , then read data from the other board , and compare with its write buffer.
View full article
Few issues encountered trying to build L5.1.1_2.1.0 Android for i.MX6: (some of them can apply to Android M6 build also) Issue-1: OpenJDK-7 required to build L5.1.1_2.1.0 but not able to download/install in Ubuntu 16.04: solution: Ubuntu 16.04 and openjdk 7 - Ask Ubuntu =============================== sudo add-apt-repository ppa:openjdk-r/ppa sudo apt-get update sudo apt-get install openjdk-7-jdk =============================== Issue-2: without any modification, got error message like: "You have tried to change the API from what has been previously approved." during compilation. solution: follow the suggestion in the error message, do "make update-api" Issue-3: error messages like ========================================= external/libcxx/include/thread:149: error: unsupported reloc 43 clang: error: linker command failed with exit code 1 (use -v to see invocation) build/core/host_shared_library_internal.mk:44: recipe for target 'out/host/linux-x86/obj32/lib/libc++.so' failed make: *** [out/host/linux-x86/obj32/lib/libc++.so] Error 1 ========================================= related post on Internet: http://stackoverflow.com/questions/36048358/building-android-from-sources-unsupported-reloc-43 https://bbs.archlinux.org/viewtopic.php?id=209698 solution:(as mentioned in the link above) replaced "prebuilts/gcc/linux-x86/host/x86_64-linux-glibc2.15-4.6/x86_64-linux/bin/ld" with the symlink to "/usr/bin/ld.gold" so this should look like: ========================================= ~/myandroid/prebuilts/gcc/linux-x86/host/x86_64-linux-glibc2.11-4.6/x86_64-linux/bin$ ls -l ld* lrwxrwxrwx 1 jimlin jimlin      16     May  6 14:48 ld -> /usr/bin/ld.gold -rwxrwxr-x 1 jimlin jimlin 1645584 May  6 11:24 ld.bfd -rwxrwxr-x 1 jimlin jimlin 3497448 May  6 11:24 ld.gold -rwxrwxr-x 1 jimlin jimlin 3497448 May  6 11:24 ld.org ========================================= to this point I can build L5.1.1_2.1.0 successfully.(on 2016, May, 12.) Issue-4: can't run the SD tool "fsl-sdcard-partition.sh" used to partition/format SD card in "~/myandroid/device/fsl/common/tools" root-cause: in Ubuntu 16.04, "sfdisk" tool doesn't support "-u" parameter: ================================== sfdisk from util-linux 2.27.1 -u, --unit S              deprecated, only sector unit is supported ================================== error message encountered when running the script: ================================== ~/myandroid/device/fsl/common/tools$ sudo ./fsl-sdcard-partition.sh /dev/sdc sfdisk: unsupported unit 'M' sfdisk: unsupported unit 'M' ================================== I've modified the script a bit to adapt the changes, as attached.
View full article
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
View full article
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
View full article
Multiple-Display means video playback on multiple screens. In case playback needs to be in a unique screen, the mfw_isink element must be used and some pipelines examples can be found on this link: GStreamer iMX6 Multi-Overlay. Number of Displays Display type Kernel parameters Pipelines # Set these shells variables before running the pipelines alias gl=gst-launch SINK_1="\"mfw_v4lsink device=/dev/video17\"" SINK_2="\"mfw_v4lsink device=/dev/video18\"" SINK_3="\"mfw_v4lsink device=/dev/video20\"" media1=file:///root/media1 media2=file:///root/media2 media3=file:///root/media3 2 hdmi + lvds video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24 video=mxcfb1:dev=ldb,LDB-XGA,if=RGB666 gl playbin2 uri=$media1 video-sink=$SINK_1 playbin2 uri=$media2 video-sink=$SINK_2 2 lvds + lvds video=mxcfb0:dev=ldb,LDB-XGA,if=RGB666 video=mxcfb1:dev=ldb,LDB-XGA,if=RGB666 gl playbin2 uri=$media1 video-sink=$SINK_1 playbin2 uri=$media2 video-sink=$SINK_2 2 lcd + lvds video=mxcfb0:dev=lcd,800x480M@55,if=RGB565 video=mxcfb1:dev=ldb,LDB-XGA,if=RGB666 gl playbin2 uri=$media1 video-sink=$SINK_1 playbin2 uri=$media2 video-sink=$SINK_2 3 hdmi + lvds + lvds video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24 video=mxcfb1:dev=ldb,LDB-XGA,if=RGB6 video=mxcfb2:dev=ldb,LDB-XGA,if=RGB666 gl playbin2 uri=$media1 video-sink=$SINK_1 playbin2 uri=$media2 video-sink=$SINK_2 playbin2 uri=$media3 video-sink=$SINK_3
View full article
This is a series of documents that intend to help you grasp he concept of the System Controller Unit (SCU) / System Controller Firmware (SCFW).    Getting started Power management service  Resource management service Pad configuration service Timer service Miscellaneous service   Other Useful resources: https://community.nxp.com/docs/DOC-344684 (2019) i.MX 8 System Controller Unit and System Controller Firmware Overview (2018) Clusters & Infotainment: Introduction to the i.MX 8 System Controller Unit (2017 Slightly outdated, for correct boot sequence go to Chapter 5 System Boot of the Reference Manual) System Controller Firmware command line utility for QNX and Linux You can get the latest System Controller Firmware Porting kit from the i.MX Software and development webpage: The porting kit contains documentation and allows you to build the SCFW from source and do modifications to the board dependent parts: The API documents explain the System Controller Firmware API syntax and it has a section for introduction and general overview of the system. The port document contains information on what each board component function does and the overall process of porting the SCFW.
View full article
Overview AVB/TSN Wikipedia: Audio Video Bridging (AVB) is a common name for the set of technical standards which provide improved synchronization, low-latency, and reliability for switched Ethernet networks. AVB was initially developed by the Institute of Electrical and Electronics Engineers (IEEE) Audio Video Bridging task group of the IEEE 802.1 standards committee. In November 2012, Audio Video Bridging task group was renamed to Time-Sensitive Networking (TSN) task group to reflect the expanded scope of its work, which is to "provide the specifications that will allow time-synchronized low latency streaming services through IEEE 802 networks". Further standardization efforts are ongoing in IEEE 802.1 TSN task group.   AVB and TSN technologies and standards: Standard Area of Definition Title of Standard AVB/TSN IEEE 802.1AS Timing and synchronization Timing and Synchronization for Time-Sensitive Applications (gPTP) AVB TSN IEEE 802.1Qav Forwarding and queuing Forwarding and Queuing for Time-Sensitive Streams (FQTSS) AVB IEEE 802.1Qat Path control and reservation Stream Reservation Protocol (SRP) AVB IEEE 802.1BA Bridging Audio Video Bridging (AVB) Systems AVB IEEE 1722 AVTP AV transport Layer 2 Transport Protocol for Time Sensitive Applications AVB IEEE 1722 AVDECC Device manage and control Device Discovery, Enumeration, Connection Management and Control Protocol AVB IEEE 802.1Qbu and IEEE 802.3br Forwarding and queuing Frame preemption TSN IEEE 802.1Qbv Forwarding and queuing Enhancements for scheduled traffic TSN IEEE 802.1Qca Path control and reservation Path control and reservation TSN IEEE 802.1Qcc Central configuration method Enhancements and performance improvements TSN IEEE 802.1Qci Time-based ingress policing Per-stream filtering and policing TSN IEEE 802.1CB Seamless redundancy Frame replication and elimination for reliability TSN   Since many of the standards are only for TSN switch/bridges and i.MX8MP is design to be a TSN/AVB endpoint, this demo does not implement a full stack or full standards. It only demonstrates the basic end-to-end point (talker to listener) A/V streaming without bridge or switch.   Below table shows what this demo supports: Standard Software Hardware IEEE 802.1AS Linuxptp ENET_QoS IP IEEE 802.1Qav/Qbu/Qbv TC qdisc (taprio, mqprio, etf, cbs) ENET_QoS IP (multi queue + EST, FPE, CBS) IEEE 1722 AVTP Libavtp N/A   Demo introduction Two i.MX8MP EVK boards are used for this demo, one act as a AVB talker to send A/V streams, the other one act as a AVB listener to receive A/V streams who can be playback to audio codec and sink video to screen. The two boards are connected by a RJ45 ethernet cable on each ENET2 port (only ENET2 port has TSN features). Three streams’ type and SR (Stream Reservation) class are defined as below to grantee time sensitive (sub-microsecond synchronization), low latency and bandwidth on the ethernet: Stream A: SR class A, AVTP Compressed Video Format, H.264 profile High, 1920x1080, 30 fps. Stream B: SR class B, AVTP Audio Format, PCM 16-bit sample, 48 kHz, stereo, 12 frames per AVTPDU. Other stream: Best-effort streams These three TSN streams would be allocated into different traffic control (TC) class for egress in Linux. Different TC class would be mapped to different hardware queues with dedicated DMA channel, thanks to the multi-queue support by ENET_QoS IP. Then the traffic control apply different scheduling policy on each queues for different types of streams egress, to make sure highest priority or critical packet can be sent in the correct time slot. The TSN streams are transmitted over Virtual LANs (VLANs). Bridges use the VLAN priority information (PCP) to identify Stream Reservation (SR) traffic classes which are handled according to the Forward and Queuing Enhancements for Time-Sensitive Streams (FQTSS) mechanisms described in Chapter 34 of the IEEE 802.1Q standard.   The demo is built up by following blocks: Linux TC (traffic control): streams egress control to meet AVB/TSN requirements, which take advantage of the i.MX8MP TSN ENET IP. Linux PTP: clock sync in network, which take advantage of the i.MX8MP TSN ENET IP. Libavtp: Time Sensitive Applications AV Transport protocol. ALSA: AVTP audio format plugin uses the libavtp to transmit and receive AVTP audio PCM streams. Gstreamer: avtp plugin uses the libavtp to transmit and receive AVTP audio/video streams (video should be encoded as H264, audio PCM). x264enc and libav is a software H.264 video encoder/decoder, which alternative to the on chip VPU acceleration plugin, due to the VPU plugin is not supported in the latest Gstreamer version (1.17.x).     Traffic control This demo can use two different traffic control qdisc settings: mqprio + cbs: use CBS features taprio + pfifo: use EST and FPE features (802.1Qbu/bv). The pfifo is the default traffic control class, which use FIFO schedule policy for egress packets. The CBS class is actually handled by hardware IP to select which queue for transmit in a certain time slot.   Credit Base Shaper (CBS) CBS parameters come straight from the IEEE 802.1Q-2018 specification. They are the following: idleSlope: rate credits are accumulated when queue isn’t transmitting; sendSlope: rate credits are spent when queue is transmitting; hiCredit: maximum amount of credits the queue is allowed to have; loCredit: minimum amount of credits the queue is allowed to have;     Enhancements to Scheduled Traffic (EST) The IEEE 802.1Qbv defines the schedule for each of the queues on every egress port which makes the implementation aware of traffic arrival schedule. This information can be used to block the lower priority traffic from transmission in this time window/slot. This ensures that scheduled traffic is forwarded from sender to receiver through all the network nodes with a deterministic delay. The i.MX8MP uses the gate control list with configurable time slot and frame preempt (IEEE 802.1Qbu) features to support EST. Other than the CBS, the gate control list control the egress transmission by a fixed open interval for that queue.   Build demo Build L5.4.24_2.1.0 $MACHINE=imx8mpevk DISTRO=fsl-imx-xwayland source imx-setup-release.sh -b build-8mp $bitbake  fsl-image-validation-imx Prepare a SD card and burn it with the built out images. To add tc/tcpdump command in iproute2 package, please add package into IMAGE_INSTALL_append variable into conf/local.conf: IMAGE_INSTALL_append = " iproute2 iproute2-tc tcpdump Rebuild kernel Rebuild the kernel after applying the 0001-qenet-add-queue-avoid-panic.patch (attached), and overwrite the Image and imx8mp-evk.dtb on the boot partition of the SD card.   Install the toolchain $bitbake -f fsl-image-validation-imx -c populate_sdk $sh tmp/deploy/sdk/fsl-imx-xwayland-glibc-x86_64-fsl-image-validation-imx-aarch64-imx8mpevk-toolchain-5.4-zeus.sh The toolchain would be installed into /opt/fsl-imx-xwayland/5.4-zeus/   Create a install folder $mkdir <your install folder> Create a folder to install all of the shared libraries, binaries and configure files which built out manually in this doc. After built done, you should copy all of the contents in this folder to target board root.   Build libavtp $source /opt/fsl-imx-xwayland/5.4-zeus/environment-setup-aarch64-poky-linux $git clone https://github.com/Avnu/libavtp.git $cd libavtp $meson build $ninja -C build Copy the built out .so and .pc into the toolchain rootfs: $sudo cp build/libavtp.so* /opt/fsl-imx-xwayland/5.4-zeus/sysroots/aarch64-poky-linux/usr/lib/ $sudo cp build/meson-private/*.pc /opt/fsl-imx-xwayland/5.4-zeus/sysroots/aarch64-poky-linux/usr/lib/pkgconfig/ To make sure you have avtp package installed correctly: $pkg-config --list-all | grep avtp Copy the .so into the install folder: $cp build/libavtp.so* <install folder>/usr/lib/ Copy header files: $cp libavtp/include/* files <toolchain_path>/sysroots/aarch64-poky-linux/usr/lib Build ALSA aaf plugin The AAF (ALSA AVTP Audio Format) plugin is a PCM plugin that uses Audio Video Transport Protocol (AVTP) to transmit/receive audio samples through a Time-Sensitive Network (TSN) capable network. The plugin enables media applications to easily implement AVTP Talker and Listener functionalities.   $cd <yocto build>/tmp/work/aarch64-mx8mp-poky-linux/alsa-plugins/1.1.9-r0/alsa-plugins-1.1.9 $./configure --build=x86_64-linux --host=aarch64-poky-linux --target=aarch64-poky-linux --prefix=<your install folder>/usr --disable-silent-rules --disable-dependency-tracking --with-libtool-sysroot=/opt/samba/nxa23059/jailhouse/yocto-5.x/build-8mp/tmp/work/aarch64-mx8mp-poky-linux/alsa-plugins/1.1.9-r0/recipe-sysroot  --disable-static  --enable-aaf --disable-jack --disable-libav --disable-maemo-plugin --disable-maemo-resource-manager --enable-pulseaudio --enable-samplerate --with-speex=lib $make $make install   Build Gstreamer AVTP plugins Build Gstreamer 1.17.x (commit e4f7cdb0df7b) $git clone https://gitlab.freedesktop.org/gstreamer/gstreamer.git $cd gstreamer $patch -p1 < gstreamer-1.0-pass-build.patch $meson build --prefix=<your install folder>/usr $ninja -C build $ninja -C build install After Gstreamer is installed into <your install folder>, please fix the “prefix” path in the .pc files by, and copy to the toolchain folders: $cd <your install folder> $grep -lR <your install folder> ./lib/pkgconfig/ | xargs sed -i 's/<your install folder>/\/usr/g' NOTE: Make sure you use the ‘\’ for ‘/’ convert in your path. $cp -rf ./usr/* /opt/fsl-imx-xwayland/5.4-zeus/sysroots/aarch64-poky-linux/usr/   Build gst-plugins-base (commit 22827e8f) $git clone https://gitlab.freedesktop.org/gstreamer/gst-plugins-base.git $cd gst-plugins-base $patch -p1 < gst-plugins-base-pass-build.patch $meson build --prefix=<your install folder>/usr $ninja -C build $ninja -C build install   Build gst-plugins-bad (commit ed14e0d5a) $git clone https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad.git $cd gst-plugins-bad $meson build --prefix=<your install folder>/usr $ninja -C build $ninja -C build install If you met gdbus-codegen issue, please remove the “--c-generate-autocleanup” and “--output-directory” parameters in the build/build.ninja If you met issue of include file like: “…/gst/gl/gstglapi.h:24:10: fatal error: gst/gl/gstglconfig.h: No such file or directory.” Please modify the build/build.ninja to correct the -I header file parameter of the build. After gst-plugins-base and gst-plugins-bad installed into <your install folder>, please fix the “prefix” path in the .pc files and copy them into the toolchain folders: $cd <your install folder> $grep -lR <your install folder> ./lib/pkgconfig/ | xargs sed -i 's/<your install folder>/\/usr/g' NOTE: Make sure you use the ‘\’ for ‘/’ convert in your path. $cp -rf ./usr/* /opt/fsl-imx-xwayland/5.4-zeus/sysroots/aarch64-poky-linux/usr/   Build H.264 SW plugins AVTPDU uses H.264 as payload for streaming, this requires H.264 encoder/decoder plugins, either software or hardware accelerations. Since we upgrade the Gstreamer and its plugins to a new version, the VPU plugins cannot be used anymore. So software H.264 plugins are required: x264 for encoder, libav for decoder.   Build x264 As the yocto actually has the x264 recipes, but not included in our bblayers, we need to copy the x264 source into our bblayers path under <yocto>/source to build: $cp -rf ./poky/meta/recipes-multimedia/x264 ./meta-openembedded/meta-multimedia/recipes-multimedia/ $vi ./meta-openembedded/meta-multimedia/recipes-multimedia/x264_git.bb Remove the LICENSE_FLAGS line $bitbake -f x264 -c do_install $sudo cp -rf tmp/work/aarch64-poky-linux/x264/r2917+gitAUTOINC+72db437770-r0/image/usr/* /opt/fsl-imx-xwayland/5.4-zeus/sysroots/aarch64-poky-linux/usr/ Build gst-plugins-ugly (commit 995a135d) $git clone https://gitlab.freedesktop.org/gstreamer/gst-plugins-ugly.git $cd gst-plugins-ugly$meson build --prefix=<your install folder>/usr $ninja -C build $ninja -C build install If you met build issue, please remove "if have_cxx" from meson.build Build libav As the yocto actually has the libav recipes, but not included in our bblayers, we need to copy the its source into our bblayers path under <yocto>/source: $cp -rf ./poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav ./meta-openembedded/meta-multimedia/recipes-multimedia/gstreamer $vi ./meta-openembedded/meta-multimedia/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.16.1.bb Remove the LICENSE_FLAGS line $bitbake -f gstreamer1.0-libav -c do_install $cp tmp/work/aarch64-mx8mp-poky-linux/gstreamer1.0-libav/1.14.0-r0/image/usr/lib/gstreamer-1.0/libgstlibav.so <your install folder>/usr/lib/gstreamer-1.0 Now you have all of the Gstreamer plugins which required for AVB/TSN audio/video demo: avtpsrc, avtpsink, avtpaafpay, avtpaafdepay, avtpcvfpay, avtpcvfdepay x264_enc (encoder), avdec_h264 (decoder)   Install binaries Final step is to copy all of your built out files from <your install folder> into your board / root, and boot up the board. Verify the Gstreamer plugins install correctly or not: $export GST_PLUGIN_PATH= /usr/lib/gstreamer-1.0/ $gst-inspect-1.0 Check if the above Gstreamer plugins we built out can be found by gst-instpect.   System Setup VLAN The ENTE_QoS is assigned to eth1 instance. So create eth1.5 for vlan id 5: $ip link add link eth1 name eth1.5 type vlan id 5 \         egress-qos-map 2:2 3:3 $ip link set eth1.5 up Qdiscs The TSN control plane is implemented through the Linux Traffic Control (TC) System. The transmission algorithms specified in the Forwarding and Queuing for Time-Sensitive Streams (FQTSS) chapter of IEEE 802.1Q-2018 are supported via TC Queuing Disciplines (qdiscs). Linux currently provides the following qdiscs relating to TSN: Multiply queue qdiscs (These two qdiscs are mutually exclusive, select one for your demo): MQPRIO: Mapping the TC class into different hardware queue in IP. TAPRIO: Implements the Enhancements for Scheduled Traffic introduced by IEEE 1Qbv/Qbu. This is supported by i.MX8MP ENET_QoS IP through EST features: Qbv – Time aware shaper Qbu - frame preemption. CBS qdisc: Implements the Credit-Based Shaper introduced by the IEEE 802.1Qav This is supported by i.MX8MP ENET_QoS IP through EST (Enhancements to Scheduled Traffic) features. It works with mqprio qdisc together. ETF qdisc: While not an FQTSS feature, Linux also provides the Earliest TxTime First (ETF) qdisc which enables the LaunchTime Since the i.MX8MP ENET_QoS IP does not support LaunchTime feature, this qdisc configurations would be ignored.   MQPRIO qdisc $tc qdisc add dev eth1 parent root handle 100 mqprio \         num_tc 3 \         map 0 0 2 1 0 0 0 0 0 0 0 0 0 0 0 0 \         queues 1@0 1@1 1@2 \         hw 1 NOTE, since ENET_QoS Q0 does not support hardware CBS, we have to avoid using Q0 for AVB streaming. Here’s the mapping: socket SO_PRIORITY 2 -> TC CLASS 2 -> Q2 socket SO_PRIORITY 3 -> TC CLASS 1 -> Q1 Other socket priority -> TC CLASS 0 -> Q0   TAPRIO qdisc Create a root qdisc handle to map the different CLASS streams to hardware queues w/ GCL (gate control list). This root handle maps the CLASS A stream to queue Q1, CLASS B stream to Q2, and others to Q0 by the “map” and “queues” parameters, same as mqprio above. The Q1/Q2(CLASS1/2) gates are open in the first 300us interval, then only Q1(CLASS1) gate is open in the next 300us with all other CLASS gated. The last sched-entry defines in after Q1 is open after 300us, all of the CLASS gates are open for next 200us. Then loopback to the first sched-entry for gate control. Please note in this demo, we only enable features to support the 802.1Qbv, the Qbu (Frame preempt) requires patches for iproute2. $tc qdisc add dev eth1 parent root handle 100 taprio \         num_tc 3 \         map 0 0 2 1 0 0 0 0 0 0 0 0 0 0 0 0 \         queues 1@0 1@1 1@2 \         base-time 1000000000 \         sched-entry S 0x6 300000 \         sched-entry S 0x2 300000 \         sched-entry S 0x7 200000 \         flags 0x2   CBS qdisc Q1 CBS for video, Q2 CBS for audio: $tc qdisc replace dev eth1 parent 100:2 handle 777 cbs \         idleslope 98688 sendslope -901312 hicredit 153 locredit -1389 \         offload 1 $tc qdisc replace dev eth1 parent 100:3 handle 888 cbs \         idleslope 3648 sendslope -996352 hicredit 12 locredit -113 \        offload 1 NOTE: By default, the Q0 will be allocated for pfifo qdisc class if we do not define them.   ETF qdisc As ENET_QOS does not support hardware launch time in IP, the ETF qdisc would not be used here.   TimeSync Run the ptp4l and phc2sys in background, and use check_clocks to check the ptp sync works. $ptp4l -i eth1 -f ./gPTP.cfg --step_threshold=1 & $pmc -u -b 0 -t 1 "SET GRANDMASTER_SETTINGS_NP clockClass 248 \         clockAccuracy 0xfe offsetScaledLogVariance 0xffff \         currentUtcOffset 37 leap61 0 leap59 0 currentUtcOffsetValid 1 \         ptpTimescale 1 timeTraceable 1 frequencyTraceable 0 \         timeSource 0xa0" $phc2sys -s eth1 -c CLOCK_REALTIME --step_threshold=1 \         --transportSpecific=1 -w &  $./check_clocks -d eth1 The PTP Hardware Clock (PHC)  synced between PTP master/slave means the RMS offset between PHC and GM (master clock) is < 100ns. PHC and system clock (CLOCK_REALTIME) synced means the clock offset < 100ns   NOTE: The check_clocks source code can be downloaded from here. cfg is described below, if you want to identify which is master and which is slave, use “masterOnly 1” or “slaveOnly 1” in this configuration file. #                                                                 # 802.1AS example configuration containing those attributes which # differ from the defaults.  See the file, default.cfg, for the   # complete list of available options.                              #                                                                 [global]                                                          gmCapable               1                                         priority1               248                                        priority2               248                                       logAnnounceInterval     0                                         logSyncInterval         -3                                        syncReceiptTimeout      3                                          neighborPropDelayThresh 800                                       min_neighbor_prop_delay -20000000                                 assume_two_step         1                                         path_trace_enabled      1                                         follow_up_info          1                                         transportSpecific       0x1                                        ptp_dst_mac             01:80:C2:00:00:0E                         network_transport       L2                                        delay_mechanism         P2P                                        Run demo ALSA AAF audio To run the alsa AAF demo, please add aaf0 and converter0 plugin device into /etc/asound.conf: pcm.aaf0 {         type aaf         ifname eth1.5         addr 01:AA:AA:AA:AA:AA         prio 2         streamid AA:BB:CC:DD:EE:FF:000B         mtt 50000         time_uncertainty 1000         frames_per_pdu 12         ptime_tolerance 100 }    pcm.converter0 {         type linear         slave {                 pcm "hw:2,0"                 format S16_LE         } }   The “aaf0” plugin device defines the ethernet interface which AAF runs on, the socket priority which mapping to Traffic Class in kernel TC, the stream-id for the aaf streaming. The “converter0” plugin device is used for convert the S16_BE format to S16_LE for the wm8960 PCM audio.   Select one device as AVB talker, and run: $speaker-test -p 25000 -F S16_BE -c 2 -r 48000 -D aaf0 Select one device as AVB talker, and run: $arecord -F 25000 -t raw -f S16_BE -c 2 -r 48000 -D aaf0 | aplay -F 25000 -t raw -f S16_BE -c 2 -r 48000 -D converter0 You can hear the sound on the listener device. You can also check which qdisc queue is used for AAF by: $tc -s qdisc   Gstreamer AAF audio Select one device as AVB talker, and run: $gst-launch-1.0 clockselect. \( clock-id=realtime \     audiotestsrc samplesperbuffer=12 is-live=true ! \     audio/x-raw,format=S16BE,channels=2,rate=48000 ! \     avtpaafpay mtt=50000000 tu=1000000 streamid=0xAABBCCDDEEFF000B processing-deadline=0 ! \     avtpsink ifname=eth1.5 address=01:AA:AA:AA:AA:AA priority=2 processing-deadline=0 \)   Select one device as AVB listener, and run: $gst-launch-1.0 clockselect. \( clock-id=realtime \     avtpsrc ifname=eth1.5 ! avtpaafdepay streamid=0xAABBCCDDEEFF000B ! \     queue max-size-bytes=0 max-size-buffers=0 max-size-time=0 ! \     audioconvert ! audioresample !  alsasink device="hw:2,0" \)   Gstreamer CVF video Select one device as AVB talker, and run: $gst-launch-1.0 clockselect. \( clock-id=realtime \     videotestsrc is-live=true ! video/x-raw,width=480,height=320,framerate=15/1 ! \     clockoverlay ! x264enc bframes=0  key-int-max=1 speed-preset=1 tune=4 ! h264parse config-interval=-1 ! \     avtpcvfpay processing-deadline=20000000 mtu=1400 mtt=2000000 tu=125000 streamid=0xAABBCCDDEEFF000A ! \     avtpsink ifname=eth1.5 priority=3 processing-deadline=20000000 \) NOTE: To eliminate the h.264 software encoding/decoding overhead with acceptable latency for this demo, we use several parameters for x264enc element: bframes: x264enc and avdec_h264 together was found to have issues, remove bframes in the stream would help. key-int-max: decoder can only decode the frame when a keyframe is present on stream to make sure decoder can work as faster as it can, the distance between two keyframes must be set to closest. speed-preset: to low down the CPU loading for encoding, we use the option to make encoding as faster as we can. (=1 means ultrafast) tune: 4 means zero latency ‘mtu=1400’ parameters for avtpcvfpay element is very important, if using the default mtu=1500, the listener cannot get the AVTPDUs package correctly from VLAN. The reason is unknown yet.   Select one device as AVB listener, and run: $gst-launch-1.0 clockselect. \( clock-id=realtime \     avtpsrc ifname=eth1.5 ! avtpcvfdepay streamid=0xAABBCCDDEEFF000A ! \     queue max-size-bytes=0 max-size-buffers=0 max-size-time=0 ! \     avdec_h264 ! videoconvert ! clockoverlay halignment=right ! waylandsink \)   The demo screenshot below: there are two clocks show on the videotestsrc stream: left one is the timestamp recorded before x264enc encoding on the AVB talker side, right one is the timestamp recorded after avdec_h265 decoding and do video convert to YUV frames on AVB listener side. You can see the timestamp is sync in seconds.     Deep dive Packet sniffer Use tcpdump on board to dump the L2 ethernet packet: ./tcpdump -i eth1 ether proto 0x22f0 -w dump.pcap The AVTP ether protocol code is 0x22f0 embedded inside the ether frame, or you can use "vlan 5" VLAN id for tcpdump parameters to dump. Then open this dump.pcap in the windows/Linux PC by the wireshark tool, it will automatically show the protocol inside the package, it can also parser the IEEE1722 (AVTP) CVF/AFF package header as below:   Precise latency measurement The clockoverlay plugin used in the above talker/listener is actually seconds level precision, which can not reflect the latency from talker videotestsrc -> listener avdec_h264 decoding finish. Here need a little hack to the clockoverlay element in the gst-plugins-base to get the millisecond precision. The patch is attached (gst-plugins-base-clockoverlay-us.patch), please apply and rebuild the gst-plugins-base, then replace the libgstpango.so on the board /usr/lib/gstreamer-1.0/. When doing CVF demo, you can take a picture of the screen, and check the two clock's diff. During my test, the latency is about 50ms, which include all the cost of encoding, AVTP packaging, streaming, ethernet transmit, ethernet receive, AVTP unpack and frame decoding. To measure the package latency from transmit port (talker) to receive port (listener), you can use the tcpdump on both end-points. And compare the Epoch Time the packet dumped: "Epoch Time: 1596252905.688243000 seconds". The delta of the epoch time of the same packet is around 100us~500us. This latency actually includes the AF_PACKET clone cost in kernel netfilter, also the tcpdump application schedule latency.   References Getting started with AVB on Linux: https://tsn.readthedocs.io/avb.html TSN vs AVB: https://dornerworks.com/blog/avb-vs-tsn-choose-the-best-deterministic-ethernet-solution-for-your-networked-devices/ ALSA aaf: https://fossies.org/linux/alsa-plugins/doc/aaf.txt Gstreamer avtp: https://gstreamer.freedesktop.org/documentation/avtp/index.html AVTP: https://avnu.org/wp-content/uploads/2014/05/AVnu-AAA2C_Audio-Video-Transport-Protocol-AVTP_Dave-Olsen.pdf MX8MP RM
View full article
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. i.MX 8/8X DDR Tools Overview   This page contains the latest releases for the i.MX 8/8X DDR Tools. The tools described on this page cover the following i.MX 8/8X Family SoCs with the System Controller Unit (SCU): i.MX 8QuadMax and its derivatives i.MX 8QuadPlus i.MX 8QuadXPlus and its derivatives i.MX 8DualXPlus and i.MX 8DualX  i.MX 8DXL (i.MX 8XLite) and its derivatives i.MX 8SXL  NOTE: For the i.MX 8M Family of DDR tools please refer to the : i.MX 8M Family DDR Tool Release                           The purpose of the i.MX 8/8X DDR Tools is to enable users to generate and test a custom DRAM initialization based on their device configuration (density, number of chip selects, etc.) and board layout (data bus bit swizzling, etc.).  This process equips the user to then proceed with the bring-up of a boot loader and an OS.  Once the OS is brought up, it is recommended to run an OS-based memory test (like Linux memtester) to further verify and test the DDR memory interface.     The i.MX 8/8X DDR Tools consist of: DDR Register Programming Aid (RPA) DDR Stress test   For more details regarding these DDR tools and their usage, refer to the MX8X_DDR_Tools_quickstart_guide.pdf attached to this page.   i.MX 8/8X DDR Register Programming Aid (RPA)   The i.MX 8/8X DDR RPA (or simply RPA) is an Excel spreadsheet tool used to develop DDR initialization for a user’s specific DDR configuration (DDR device type, density, etc.). The RPA generates the DDR initialization in two formats (in separate Excel worksheet tabs):   DDR Stress Test script: This format is used specifically with the DDR stress test by first copying the contents in this worksheet tab and then pasting it to a text file, naming the document with the “.ds” file extension. The user will select this file when executing the DDR stress test. DCD CFG file: This format is the configuration file used specifically by the SCU Firmware (SCFW). In this scenario, the user copies the contents in this worksheet tab and pastes it to a text file, naming the document with the “.cfg” file extension and placing this file in the appropriate SCFW board file directory.   i.MX 8/8X DDR Register Programming Aid (RPA): Current Versions Note: In all cases, the RPA revision is aligned to a minimum SCFW version as shown in the table below. In some cases, the BSP alignment is provided as extra detail, however, the RPA tool is specifically aligned to a minimum SCFW version and later. To obtain the latest RPAs, please refer to the following links (note, existing RPAs have been removed from this main page and moved to the SoC specific links below): i.MX8QM: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8QM-DDR-Register-Programming-Aid-RPA/ta-p/1166307 i.MX8QXP/QXP/DX: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8QXP-DXP-DX-DDR-Register-Programming-Aid-RPA/ta-p/1166302 i.MX8DXL/SXL: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8DXL-DDR-Register-Programming-Aid-RPA/ta-p/1602262   Processor Mask Revisions Memory Supported Latest RPA Version * Notes i.MX 8QM B0 LPDDR4 Rev 23*** Rev 22** Rev 21** Rev 20** Rev 19** Rev 23: IMPORTANT: this is aligned to SCFWv1.7.0 (and later SCFW versions). When using SCFWv1.7.0 (and later SCFW versions), you must use this version or later RPA and cannot use earlier versions of the RPA. See note at end of table. Rev22: The following changes have no effect on the DDR IO interface. This updated setting basically adds a define in the DCD file for the total DDR density configured by the RPA. This defined is used by the SCFW.  Rev 21: Fixed 1 DRC operation to comment out calls to VREF training to DRC1 and added DDRC_SCHED register programming to align with latest SCFW programming (refer to RPA revision history for more details). Rev 20: use with SCFW 1.4.0 and NXP BSP GA version L5.4.3_2_0_0 later (to support SW VREF training work around command) Rev 19: use with SCFW 1.3.1 and NXP BSP GA version L5.4.3_1_0_0 i.MX 8QXP C0, B0 LPDDR4 Rev 16*** Rev 15** Rev 14** Rev 13** Rev 16: IMPORTANT: this is aligned to SCFWv1.7.0 (and later SCFW versions). When using SCFWv1.7.0 (and later SCFW versions), you must use this version or later RPA and cannot use earlier versions of the RPA. See note at end of table. Rev 15: The following changes have no effect on the DDR IO interface. This updated setting basically adds a define in the DCD file for the total DDR density configured by the RPA. This defined is used by the SCFW.  Rev 14: use with SCFW 1.4.0 and NXP BSP GA version L5.4.3_2_0_0 later (to support SW VREF training work around command) Rev 13: use with SCFW 1.3.1 and NXP BSP GA version L5.4.3_1_0_0 i.MX 8QXP C0, B0 DDR3L Rev 23 Rev 22*** Rev 21 Rev 20 Rev 23:  -Corrected Register Configuration DDR_PHY_PTR4.tDINIT1 bit field programming. Previously, the calculation was based on tRFC only, however, the calculation should have been based on "tRFC+10ns". This was corrected. -Set DDRC_INIT4, DDR3 MR2.ASR=1 as the default setting to allow for the DRAM to select the self refresh rate automatically based on its case temperature (but user has the option to disable via pull-down menu). Also, removed conditional setting for DTCR0.DTRDBITR as it is not needed since DDR3 does not support DBI. Default setting of this was zero and will remain that way. -Provided option to user to select auto refresh rate based on the intended max temperature of the DDR3L device (1X, 2X, 4X). User should confirm with the DDR3L data sheet for supported temperature ranges and associated refresh rate. Rev 22: IMPORTANT: this is aligned to SCFWv1.7.0 (and later SCFW versions). When using SCFWv1.7.0 (and later SCFW versions), you must use this version or later RPA and cannot use earlier versions of the RPA. See note at end of table. Rev 21: The following changes have no effect on the DDR IO interface. This updated setting basically adds a define in the DCD file for the total DDR density configured by the RPA. This defined is used by the SCFW. -Compatible with SCFW 1.1.10 and later -Changes made to this revision do not affect the DCD CFG file output based on v19 -Issue discovered in the DDR stress test script, wherein certain commands were not being properly configured based on the ECC setting in the Register Configuration worksheet; this was resolved (cells A84, A87, A90, A93 ) -In addition, in both DCD CFG and DDR stress test script worksheets, all commands that depend on ECC config have been updated to include an "OR" with whether or not the data bus is configured for 16-bit (ECC is only supported for full 32-bit data bus width configurations) i.MX 8DualX C0, B0 LPDDR4 Rev 16*** Rev 15* Rev 14** Rev 13** Rev 16: IMPORTANT: this is aligned to SCFWv1.7.0 (and later SCFW versions). When using SCFWv1.7.0 (and later SCFW versions), you must use this version or later RPA and cannot use earlier versions of the RPA. See note at end of table. Rev 15: The following changes have no effect on the DDR IO interface. This updated setting basically adds a define in the DCD file for the total DDR density configured by the RPA. This defined is used by the SCFW.  Rev 14: use with SCFW 1.4.0 and NXP BSP GA version L5.4.3_2_0_0 later (to support SW VREF training work around command) Rev 13: use with SCFW 1.3.1 and NXP BSP GA version L5.4.3_1_0_0 i.MX 8DualX C0, B0 DDR3L Rev 21 Rev 20*** Rev 19 Rev 18 Rev 21: -Corrected Register Configuration DDR_PHY_PTR4.tDINIT1 bit field programming. Previously, the calculation was based on tRFC only, however, the calculation should have been based on "tRFC+10ns". This was corrected. -Set DDRC_INIT4, DDR3 MR2.ASR=1 as the default setting to allow for the DRAM to select the self refresh rate automatically based on its case temperature (but user has the option to disable via pull-down menu). Also, removed conditional setting for DTCR0.DTRDBITR as it is not needed since DDR3 does not support DBI. Default setting of this was zero and will remain that way. -Provided option to user to select auto refresh rate based on the intended max temperature of the DDR3L device (1X, 2X, 4X). User should confirm with the DDR3L data sheet for supported temperature ranges and associated refresh rate. Rev 20: IMPORTANT: this is aligned to SCFWv1.7.0 (and later SCFW versions). When using SCFWv1.7.0 (and later SCFW versions), you must use this version or later RPA and cannot use earlier versions of the RPA. See note at end of table. Rev 19: The following changes have no effect on the DDR IO interface. This updated setting basically adds a define in the DCD file for the total DDR density configured by the RPA. This defined is used by the SCFW.  -Compatible with SCFW 1.1.10 and later * For a history of the previous versions of an RPA, refer to the Revision History tab of the respective RPA.  ** In general, it is recommended to use the latest RPA tool even with a pre-released BSP as it ensures you are testing with the latest fixes and features. Older versions of the RPA may be provided to support existing/released versions of the BSP.  This only applies to those RPA tools that are compatible with pre-release BSPs but may not be compatible with released versions of the BSP.   ***IMPORTANT: as stated in the table above, for the noted RPA version, it is aligned to SCFWv1.7.0 (and later SCFW versions).  Older versions of the RPA are not aligned to SCFWv1.7.0 (and later SCFW versions).  If trying to use an older version of an RPA with SCFWv1.7.0 (and later SCFW versions), 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 */ 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 (and later SCFW versions) (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 Note: when it is stated "SCFWv1.7.0 (and later SCFW versions)", it implies SCFWv1.7.0, 1.7.1, 1.7.2... 1.8.0, 1.9.0, 1.10.0... etc., where "..." are minor versions/patches, so when you see 1.7.2... it implies 1.7.3, 1.7.4, etc.).  Unless otherwise noted, the latest RPA shown in the table above is aligned to the latest SCFW release.    i.MX 8/8X DDR Stress Test    The i.MX 8/8X DDR stress test tool is a Windows-based software tool that is used as a mechanism to verify that the DDR initialization is operational prior to building the SCFW for use with u-boot and OS bring-up. The DDR stress test uses the .ds DDR stress test script generated from the RPA tool along with a special build of the SCFW, built with option: DDR_CON=ddr_stress_test_parser Or in the case of i.MX 8QuadMax use of one DDR Controller: DDR_CON=ddr_stress_test_parser_DRC0_only The DDR stress test offers a Target option to dictate which SoC is under test. The following are Target options to select from: MX8QM – used to test i.MX 8QuadMax and its derivatives i.MX 8QuadPlus MX8QX – used to test i.MX 8QuadXPlus and its derivatives i.MX 8DualXPlus/DualX MX8DXL – used to test i.MX 8DXL and its derivatives i.MX8 SXL     To install the DDR Stress Test, save and extract the zip file mx8_ddr_stress_test_ERxx_installation.zip   (where 'xx' is the current version number) and follow the on-screen installation instructions. Note, when extracting the DDR Stress Test tool .zip file, it is recommended to perform an "Extract here" operation.  Some systems do not allow for the extracted installation executable to run from another folder and will only work when being executed from the same location as the original, downloaded zip file.  For more details on the DDR stress test usage, refer to the MX8_DDR_Tool_User_Guide found in the DDR Stress Test tool delivery. NOTE: Before using the DDR tools on a new custom board, the user should properly port the SCU Firmware (SCFW) to this new board. The DDR tools will not be able to run without a properly ported and working SCFW.            i.MX 8/8X DDR Stress Test Requirements The tool requires access to the Windows registry, hence users must run it in administrator mode. The tool cannot run on an OEM closed device that requires images signed by the customer When users design new i.MX 8/8X boards, please make sure to follow the rules outlined in the respective Hardware Developers Guide and the MX8_DDR_Tool_User_Guide, which can help users bring up DDR devices on their respective i.MX 8/8X boards.   i.MX 8/8X DDR Stress Test SECO Firmware It is generally not recommended to update the SECO (ahab) firmware that comes default with the DDR Stress Test. This is not recommended because the purpose of the DDR Stress Test is to test the DDR memory interface, not the entire SCFW to SECO firmware operation even though a newer version of the SCFW may complain that the SECO firmware version is not the latest. The SECO firmware version that comes with the DDR Stress Test has been tested and proven to work by the factory before the DDR Stress Test release; updating the SECO firmware to a different version may result in unintended consequences rendering the DDR stress test inoperable. In most cases, it is allowable to update only the SCFW without updating the SECO firmware. Should the user wish to update the SECO firmware version in the DDR Stress Test, then they will need to rename this firmware without the silicon version (for example, if updating the MX8QM SECO firmware, the user will need to rename mx8qmb0-ahab-container.img to mx8qm-ahab-container.img, basically remove the “b0”). The exception is for the MX8QXP, if updating the C0 silicon version SECO firmware, then the user should maintain the C0 nomenclature. If the user finds that the updated SECO firmware causes the DDR Stress Test to become inoperable, then it is recommended to revert to the default SECO firmware version that came with the DDR Stress Test release. i.MX 8/8X DDR Stress Test User Guide The i.MX 8/8X DDR Stress Test tool includes the document: MX8_DDR_Tool_User_Guide.pdf NOTE: Please read the MX8_DDR_Tool_User_Guide inside the package carefully before you use this tool.   DDR Stress Test Revision History   Rev Major Changes (Features) NXP BSP Software Version ER 14 Updated to support parsing of the VREF training command in the DDR Stress Test script This version is aligned with NXP BSP GA version L5.4.3_2_0_0 and later. ER15 - Support for i.MX 8Lite (aka DXL) - Provides more verbose output in event of data training failures, specifically on which byte lanes failed - Aids in debug of board layout issues This version is aligned with NXP BSP GA version Linux 5.15.71_2.2.0 and later.    Related Resources Links: i.MX 8ULP DDR tools: i.MX Software and Development Tools | NXP Semiconductors Scroll down to “Other Resources --> Tools --> DDR Tools” i.MX 8M Family DDR Tool Release  i.MX 6/7 DDR Stress test GUI Tool i.MX 8QM RPA: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8QM-DDR-Register-Programming-Aid-RPA/ta-p/1166307 i.MX 8QXP/DXP/DX RPA: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8QXP-DXP-DX-DDR-Register-Programming-Aid-RPA/ta-p/1166302 i.MX 8DXL (i.MX 8XLite) RPA: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8DXL-DDR-Register-Programming-Aid-RPA/ta-p/1602262   FAQs: Q. When the DDR stress test is running, it indicates testing region 1 and then region 2. What is region 1 and region 2? A. There are two distinct DDR memory regions in the i.MX8X series which is due to the architecture of Cortex A core and the associated memory map of the i.MX8X. Region 1 is the 32-bit region, starting at 0x080000000 and ending at 0x0FFFFFFFF (2GB total) Region 2 is the 64-bit region (for the Cortex A core architecture), starting at 0x880000000 and ends at the remaining density: • For 4GB total on board density, 2GB for region 1 and 2GB for region 2, so region 2 will end at 0x8FFFFFFFF (0x900000000 minus 1) • For 6GB total (NXP board density), 2GB for region 1 and 4GB for region 2, so region 2 will end at 0x97FFFFFFF (0x980000000 minus 1) • For 8GB total, 2GB for region 1 and 6GB for region 2, so region 2 will end at 0x9FFFFFFFF (0xA00000000 minus 1) Hence there is a “hole” in the memory map between region 1 and region 2. As such, the DDR stress test first tests the lower region (region 1) until it is exhausted (up to 2GB), and if the DDR density exceeds 2GB, the test will test the remaining density in region 2. Q. Do the i.MX8X series SoCs support LPDDR4 memories with 17 row addresses (R[16:0])? A. The i.MX8QM, i.MX8QXP, and i.MX8DXP SoCs and their derivatives cannot support newer 17-row-address LPDDR4 memories. This means, in order to support the maximum 4GB (32Gb) LPDDR4 density, the configuration must be 16-row, 2 rank (as opposed to the unsupported 17-row, 1 rank). The upcoming i.MX8DXL is planned to support 17-row address LPDDR4 devices. Q. I can select a different i.MX8X AP UART port when running the DDR Stress Test? A. It is highly recommended to follow NXP board designs including selecting the same UART ports; this eases the user’s software porting efforts and minimizes issues with needless debugging. The DDR Stress Test requires the use of the USB OTG port and the AP UART port (and it is highly recommended to connect the SCFW UART port for SCFW debug messages). To date, the factory sees no reason why the user would need to select a different AP UART port than what is used on NXP boards. Selecting the same AP UART port ensures a faster bring up of the DDR stress test rather than needlessly debugging why a different UART port is not working. In any event, some wish to use a different UART port for whatever reason, as such, NXP has placed work arounds to allow the selection of a different UART port. To select a different UART port (0,1, or 2), the user simply needs to add the following line to the end of the DDR Stress Test DDR initialization (.ds) script: memory set  0x5C01042C 32   <UART port value> memory set  0x5C01042C 32   0x00000000   # UART0 port selection for AP UART (default) memory set  0x5C01042C 32   0x00000001   # UART1 port selection for AP UART memory set  0x5C01042C 32   0x00000002   # UART2 port selection for AP UART Note that UART ports 0, 1, and 2 have pad names that are default UART pins (IOMUX ALT0 config). To date, the DDR tools do not support other UART ports that are mux’d out on other non-default UART pins. However, there is an exception for i.MX8QXP/DXP and the upcoming i.MX8DXL where UART3 mux’d out on FLEXCAN2 can be used. To select this, add the following to the end of the .ds file: memory set  0x5C01042C 32   0x00000003   # UART3 port selection for AP UART (exception for i.MX8QXP/DXP and i.MX8DXL) Some RPAs do have support built in (via a pull down menu) to select the UART port. For those RPAs that do not have this feature, this is due to the fact that these RPA (NXP boards) were not tested with a different UART port as the board requires cutting traces and re-wiring the UART signals and some boards may not have these UART traces readily available. However, the user is still able to manually add this UART port selection. Refer to the following RPAs to see the UART port select option: MX8QXP DDR3 MX8DXP DDR3 Q. Why does the DDR stress test appear to hang when testing [MX8QM with 8GB (64Gb) or MX8QXP with 4GB (32Gb)] of LPDDR4 memory? A. The issue is not caused by the DDR stress test itself but by the version of the SCFW being used. The default version of the SCFW binary pre-dates a change made by the SCFW to ignore DRAM density limitations when it detects that the DDR stress test is running. This version of the SCFW associated with the DDR stress test ER14 limits the testable DRAM density to [MX8QM: 6GB, MX8QXP: 3GB], as this version of the SCFW is configured to operate on NXP boards as a basis. As noted in the DDR stress test user guide, it is recommended for users to port the latest SCFW to their board first before using the DDR stress test to account for board differences between NXP’s board and their board.  In addition, the user has the following options to enable testing beyond [MX8QM: 6GB, MX8QXP: 3GB]; note it is the responsibility of the user to ensure a properly working, ported version of the SCFW prior to operating the DDR stress test. 1. The latest SCFW should contain an update that sets no density limit if it is detected that the SCFW is built for usage with the DDR Tool - the user can try to get the latest porting kit and build the new firmware.  This is the recommended change. 2. In board.c, function board_system_config(), there is this chunk of code (MX8QM example shown) if using an existing/older SCFW that pre-dates this change: /* Board has 6GB memory so fragment upper region and retain 4GB */         BRD_ERR(rm_memreg_frag(pt_boot, &mr_temp, 0x980000000ULL,             0xFFFFFFFFFULL)); User can modify it as follows:     if (ddrtest == SC_FALSE)     {         sc_rm_mr_t mr_temp;         /* Board has 6GB memory so fragment upper region and retain 4GB */         BRD_ERR(rm_memreg_frag(pt_boot, &mr_temp, 0x980000000ULL,             0xFFFFFFFFFULL));         BRD_ERR(rm_memreg_free(pt_boot, mr_temp));     } This is disables execution of this section of code if the SCFW is built for the DDR Tool (the same as 1. but needs to be done by the user manually when using an earlier firmware version). 3. Change 0x980000000 to 0xA00000000 in the above chunk of code. That should allow for 8GB density for MX8QM example shown above (for MX8QXP, change 0x8C0000000ULL to 0x900000000ULL for 4GB density).  
View full article
Overview Measuring the power consumed an i.MX application processor can be a challenging undertaking. This document describes several boards designed to instrument i.MX application boards for current measurements. While this system does not offer many digits of accuracy, it can be used to quantify power consumed by application use cases as well as while in low power modes. The system can be used to instrument up to four power supply rails and measure current in two ranges. Range switching on the sensor boards is controlled via software running on the Kinetis K20 at the heard of the profiler board. Measured data is sent to a host computer over a virtual serial link over USB. Power for the profiler system is obtained from the USB connection although a external 5V supply may be used. Dual-Range Current Sensors INA250 + INA21x Sensor Circuit Description: The INA250 + INA21x Sensor board can measure two ranges using the INA250 and INA21x current sense amplifiers. The high range is measured with an INA250, which has an integrated 0.002 Ohm shunt, and is available in four output gains. The low range is measured with shunt R1 and the INA21x sense amp. The low range shunt is taken out of the circuit (by shorting it) with two paralleled, very low-Rds(on) FETs, Q1 and Q1. VCC_SENSE powers the two sense amplifiers. VCC_FET supplies the gate voltage on Q1 and Q2. The DMN1019 device has a Vgs max of 8V. The sources of both FETs are tied to the i.MX side of the current sense loop, so the gate voltage Q1 and Q2 see is VCC_FET-(rail voltage). The signal /LOW_EN controls the state of both Q1 and Q2. The sense amplifier outputs (HIGH_OUT1 and LOW_OUT1) and rail voltage (V_RAIL_MEASURE) are sent down the ribbon cable (X2) to the profiler board for measurement. When not used for a wire loop for a Hall-effect current probe, resistor R3 should be shorted with a solder bridge, a piece of wire, or a 0.001 Ohm resistor. Schematic: Board Layout: The two large vias by the current sense connection points are provided for use with a 0.1" header and jumper to short the low range shunt, allowing normal operation of the target board when the profiler is not powered. It should be noted a jumper will not be as effective for relatively large currents. BOM: Part   Device C1,C2  0.1uF 0805 Q1,Q2  DMN1019USN-13 SOT23 R1     2 1% 0805 (resize to change low range) R2     10k 0805 R3     Solder bridge/wire loop (see schematic) U1     INA250 TSSOP16 (choose gain, A3 [0.8V/A] or A4 [2.0V/A]) U2     INA21X SC70 (choose desired gain) X2     WM6769CT/0527460871 (bottom contacts) Dual INA21x Sensor Circuit Description: The Dual INA21x Sensor board can measure two ranges using two INA21x current sense amplifiers and two different shunts. The high range shunt (R1) is always in place. The low range shunt is taken out of the circuit (by shorting it) with two paralleled, very low-Rds(on) FETs, Q1 and Q1. VCC_SENSE powers the two sense amplifiers. VCC_FET supplies the gate voltage on Q1 and Q2. The DMN1019 device has a Vgs max of 8V. The sources of both FETs are tied to the i.MX side of the current sense loop, so the gate voltage Q1 and Q2 see is VCC_FET-(rail voltage). The signal /LOW_EN controls the state of both Q1 and Q2. The sense amplifier outputs (HIGH_OUT1 and LOW_OUT1) and rail voltage (V_RAIL_MEASURE) are sent down the ribbon cable (X2) to the profiler board for measurement. Schematic: Board Layout: The two large vias by the current sense connection points are provided for use with a 0.1" header and jumper to short the low range shunt, allowing normal operation of the target board when the profiler is not powered. It should be noted a jumper will not be as effective for relatively large currents. BOM: Part   Device C1,C2  0.1uF 0805 Q1,Q2  DMN1019USN-13 SOT23 R1     0.002 1% 0805 (resize to change high range) R2     0.05 1% 0805 (resize to change low range) R3     10k 0805 U1,U2  INA21X SC70 (choose desired gain) X2     WM6769CT/0527460871  (bottom contacts) Four-Channel Power Profiler Circuit Description: The Four-Channel Power Profiler board has at its heart a Kinetis K20 on a Teensy3.2 board. The ADCs of the K20 measure all the current sense amplifier's outputs, the voltage of each instrumented rail. There is provision for measuring temperature using up to three thermistors. GPIO provide control each sensor board's current range, and optionally, a hardware wake-up signal for the instrumented target board. Up to four dual-range sensor boards can be connected (either sensor board mentioned above). A micro-SD card socket is included for storing measured data (the SD card functionality has been tested but not implemented for use with measurements). Measured data is sent to the host computer over a virtual serial port using the Teensy's USB. Charge pump U1 boosts the 5V supply to 12V. The output is regulated down to 8V on VCC_FET via regulator U2. R2 and C5 provide filtering for the 3.3V supply from the Teensy that feeds the sensor boards through VCC_SENSE. FETs Q1 through Q4 provide voltage level translation which protect the Teensy's GPIO pins from the 8V that's placed on the gates of the shorting FETs on the sensor boards. Regulator IC2 provides power for the micro-SD socket, since the 3.3V regulator on the Teensy does not provide enough capacity. Since there are not "smarts" on the sensor boards, the Teensy has no way of knowing what kind of sensor board is connected or what shunt values and sense amplifier gains are in use. As currently implemented, current and voltage calculations are hard coded in the Teensy application code. Schematic: Board Layout: BOM: Part    Device C1,C2   0.22uF 0805 C3-C7   1uF 0805 C10,C12 1uF 0805 C11     0.1uF 0805 IC2     MCP1825ST-3302 SOT223 Q1-Q4   DMN1019USN SOT23 R2-R4   20k 1% 0805 R5-R8   10k 0805 R9      Ferrite bead 0805 S1-S4   WM6769CT/0527460871 (bottom contacts) U$1     101-00660-68-6-1-ND MICROSD U1      MAX662CPASO8 SO08 U2      78L08SMD SO08 Use mating Molex cables: 8in: 0150200087 or 10in: 0151660091 Using the Power Profiler Obtaining Sensor and Profiler Boards: Bare boards may be ordered directly from OSH Park using these links: INA250 + INA21x Sensor board (order with 2oz copper option selected) Dual INA21x Sensor board (order with 2oz copper option selected) Power Profiler board The sensor boards should be ordered with the 2oz copper option selected to reduce the trace resistance of the target board's current path. No special option is needed for the profiler board. Teensy3.2 boards may be ordered from OSH Park as well, and at a slightly lower price than the manufacturer (PJRC) sells them. Choosing Current Ranges: To choose the value of a shunt resistor, use the following equation: Rsh = Vfs / (Ifs * gain) where: Rsh is the shunt resistance Vfs is the full scale sense amplifier output voltage (3.3V here) Ifs is the full scale current to be measured gain is the gain of the sense amp to be used For example, to measure a 66mA full scale current with a sense amp of gain 1000, Rsh = 3.3V / (0.066A * 1000) = 0.050 Ohms. For sleep/leakage current, say 1mA full scale: Rsh = 3.3V / (0.001 * 1000) = 3.3 Ohms. The pads on both sensor boards for the shunt resistors have been laid out for 0805 SMT resistors. Precision resistors should be used, 1% or better. The highest power dissipation resistor available should be used to minimize resistance change from the shunt resistor heating up; 0805 resistors are typically available with 1/8, 1/4, 1/2 and 1 Watt dissipation. Building and Testing: These boards were designed to be assembled by hand in small quantities. The most difficult components to solder are the ribbon connectors and the SC70 packaged sense amplifiers. A fine tip soldering iron and a microscope are required. Solder wick is helpful for removing solder bridges from between pins (typically the ribbon connector and the sense amplifiers).  Early versions of the profiler board were assembled with header pins soldered to the Teensy and mating female recepticles soldered to the profiler board. Later versions (like in the example below) were assembled with male header pins between the Teensy and the profiler board.  To test the boards after assembly, check for the presence of 8V on the pull-up resistors R5-R8 when a USB cable is plugged into the Teensy. Program the Teensy with suitable application code. Connect the sensor boards to the profiler. Connect all the sensor boards together in series, positive of one to negative of the next and connect to a calibrated current source. (The image below shows an early prototype of the profiler with the sensor boards connected in series. Current is forced through them via the Kelvin contact clips.) Open a terminal window on the host computer. Force known currents and toggle the ranges of each sensor to verify that each sensor operates correctly in both ranges. To check that the profiler measures rail voltage correctly, disconnect the current source and apply the positive side of a voltage source to either side of the sensors still connected in series and connect the ground of the voltage source to a ground point on the profiler. The rail voltage measured by each sensor should match the supplied voltage (0 to 3.3V max). Accuracy/Calibration: After building in excess of 20 sensor boards and 6 profiler boards and checking their measurements against a Keysight B2902 SMU forcing known currents, the profiler system is fairly accurate. Measurements are good down to about 2% of any range's full scale; lower than that gets into the input offset range of the sense amplifier. Individual readings within 1% of that range's full scale when compared against forced current values. No calibration or tuning has been necessary. Measured values should only be considered good to at most 3 significant figures. Limitations: The maximum current through any sensor should be limited to a maximum of 4A. The current limit when using the low range needs to avoid exceeding the power dissipation of the low range shunt resistor. Particularly, the dissipation in the low range shunt resistor can cause resistance changes that would affect measurement accuracy. The voltage of any instrumented rail cannot be greater than 3.3V, the maximum input voltage of the K20's ADC inputs. Minimum resistance the sensor introduces is in high range is about 0.012 to 0.015 Ohms with a 0.002 Ohm shunt. At least 0.005 Ohms comes from the two shorting FETs on the sensor board. The rest comes from the traces on the board as well as the interconnect wires. The bottom line is: the sensor board has to be mounted as closely as possible to the current sense point on the target board. The maximum resistance the sensor introduces depends on the low range shunt. With a 0.020 Ohm low range shunt, the resistance is about 0.025 to 0.030 Ohms. With a 0.050 Ohm low range shunt, the resistance is about 0.065 to 0.075 Ohms. The sensor board needs to be rigidly mounted to prevent ripping up the current sense points on the target board. This can be a challenge when many rails are instrumented. Instrumenting Target Board: When instrumenting a target board, the on-board current sense resistor should be removed. The sensor board should be attached to the target board placed as close as possible to the sense resistor pads. Connection wires to the sensor board should be as short as possible to minimize series resistance. Great care should be taken to prevent movement of the sensor boards that could in turn lift the sense resistor pads off the target board. Foam double sticky tape should be used over clear areas of the target board to avoid dislodging components when the tape is removed. In the photos below, seven power supplies are instrumented on an interposer card. In this example, the sensor boards were affixed to perf board held in place by the headers. Because of the physical constraints of the target board and its power supply card, mounting the sensor boards directly to the interposer was not possible. Four sensors were mounted on one side and three on the other. Notches were cut in the perf board for the sensor's connection wires on the opposite side. Two profiler boards are required for simultaneous use. (Two were also required because the 0.1" headers and jumpers were not installed on the sensor boards to passively short the low-range shunts; all the sensor boards need to be powered to actively short the low-range shunts.)  The positive input of the sensor board (the center of the three connection points) goes to the regulator side of the current sense resistor. The negative input (either of the two outside connections) goes to the i.MX side of the sense resistor. [NOTE: In this example, the power profiler boards have not been fully populated: the thermistor-related components and the micro-SD card socket. The sensor boards were fully populated with the exception of the passive shorting jumper.] Here is another example of a board with six instrumented rails. The sensors in this case are mounted directly on the target board. In this example, the 12V rail is instrumented, which required modding to add a voltage divider to V_RAIL_LOWSIDE on that sensor board.  And here's yet another example of an instrumented i.MX6Q SDB (which still has wires on it from measuring it the old way...). Although it's difficult to see in this photo, all of the sensor boards have a jumper across the low range shunt which permits normal operation of the board without the profiler board attached to provide power to the shorting FETs. Profiler Application Code for Kinetis/Teensy: Below is sample application code for the Teensy for use with four INA250 + INA21x sensor boards populated with the INA250A3 (0.8V/A gain) for the high range and 0.05 Ohm shunts and INA212 (gain 1000). The current range of each channel can be independently changed. This code is also attached below as a file. Data is sent to the host computer over a USB virtual serial port. To reflash/update Teensy code, follow the instructions from PJRC. Download Windows virtual com port driver. /* MIT License (https://spdx.org/licenses/MIT.html) Copyright 2017 NXP Teensy Power Profiler v.2 (revised main board with individual Hi/Lo GPIO, fixed voltage levels, and on-board uSD card socket. Very basic code for the Teensy Power Profiler that sets up the ADCs and controls the GPIO with very basic, single-character serial commands... This version for all INA250A3 on high range, and 0.05Ohms+INA212 (1000 gain) on low range. */ // These constants won't change.  They're used to give names to the pins used: const int LoHiEn1 = 0; const int LoHiEn2 = 1; const int LoHiEn3 = 2; const int LoHiEn4 = 3; const int WakeUp = 5; const int Lo_1 = A0; const int Vrail_1 = A1; const int Hi_1 = A2; const int Lo_2 = A3; const int Vrail_2 = A4;  const int Hi_2 = A5; const int Lo_3 = A6; const int Vrail_3 = A7; const int Hi_3 = A8; const int Lo_4 = A9; const int Vrail_4 = A11; const int Hi_4 = A10; const int Therm1 = A14; #include <math.h> // thermistor temperature calculation stuff... int sensorValue = 0;        // value read from the pot float sensorValuef = 0.0; int B = 4334; // B25/100 value for thermistor NXRT15WF104FA1B040 // other stuff... int delayintvl = 20; int incomingByte; float vrefL = 3.3; float vrefH = 3.3; float vrefV = 3.3; bool one=true;   bool dispone=true; bool two=true;   bool disptwo=true; bool three=true; bool dispthree=true; bool four=true;  bool dispfour=true; int i,j; int num=100; float v1, v2, v3, v4, i1, i2, i3, i4; float il1, il2, il3, il4; void setup() {   // initialize serial communications at 115200 bps:   Serial.begin(115200);   // set analog resolution to 12 bits... (we want more than the 8 default bits...)   analogReadResolution(12);   // set up low/high range wakeup GPIO signals...   pinMode(LoHiEn1, OUTPUT); digitalWrite(LoHiEn1, HIGH);   pinMode(LoHiEn2, OUTPUT); digitalWrite(LoHiEn2, HIGH);   pinMode(LoHiEn3, OUTPUT); digitalWrite(LoHiEn3, HIGH);   pinMode(LoHiEn4, OUTPUT); digitalWrite(LoHiEn4, HIGH);   pinMode(WakeUp, OUTPUT); digitalWrite(WakeUp, HIGH); } void loop() {   // average voltages and currents...   v1=0; v2=0; v3=0; v4=0;   i1=0; i2=0; i3=0; i4=0;   il1=0; il2=0; il3=0; il4=0;   for (i=0; i<num; i++){     v1 = v1+ analogRead(Vrail_1)/4095.*vrefV;     i1 = i1+ analogRead(Hi_1)/4095.*vrefH/0.8*1000;     il1 = il1+ analogRead(Lo_1)/4095.*vrefH/0.05;     v2 = v2+ analogRead(Vrail_2)/4095.*vrefV;     i2 = i2+ analogRead(Hi_2)/4095.*vrefH/0.8*1000;     il2 = il2+ analogRead(Lo_2)/4095.*vrefH/0.05;     v3 = v3+ analogRead(Vrail_3)/4095.*vrefV;     i3 = i3+ analogRead(Hi_3)/4095.*vrefH/0.8*1000;     il3 = il3+ analogRead(Lo_3)/4095.*vrefH/0.05;     v4 = v4+ analogRead(Vrail_4)/4095.*vrefV;     i4 = i4+ analogRead(Hi_4)/4095.*vrefH/0.8*1000;     il4 = il4+ analogRead(Lo_4)/4095.*vrefH/0.05;   }   v1 = v1/num; v2 = v2/num; v3 = v3/num; v4 = v4/num;   i1 = i1/num; i2 = i2/num; i3 = i3/num; i4 = i4/num;   il1 = il1/num; il2 = il2/num; il3 = il3/num; il4 = il4/num;   // print the results to the serial monitor:   if (dispone) {   Serial.print(" RAIL1 (V)= ");  Serial.print(v1);  //Serial.print("\r\n");   if (!one) {Serial.print("    L1 (mA)= ");  Serial.print(il1, 1);}  //Serial.print("\r\n");   if (1==1) {Serial.print("    H1 (mA)= ");  Serial.print(i1, 1); }   Serial.print("\r\n");   }   if (disptwo) {   Serial.print(" RAIL2 (V)= ");  Serial.print(v2);  //Serial.print("\r\n");   if (!two) {Serial.print("    L2 (mA)= ");  Serial.print(il2, 1);}  //Serial.print("\r\n");   if (1==1) {Serial.print("    H2 (mA)= ");  Serial.print(i2, 1);}    Serial.print("\r\n");   }   if (dispthree) {   Serial.print(" RAIL3 (V)= ");  Serial.print(v3);  //Serial.print("\r\n");   if (!three) {Serial.print("    L3 (mA)= ");  Serial.print(il3, 1);}  //Serial.print("\r\n");   if (1==1) {Serial.print("    H3 (mA)= ");  Serial.print(i3, 1);}    Serial.print("\r\n");   }   if (dispfour) {   Serial.print(" RAIL4 (V)= ");  Serial.print(v4);  //Serial.print("\r\n");   if (!four) {Serial.print("    L4 (mA)= ");  Serial.print(il4, 1);}  //Serial.print("\r\n");   if (1==1) {Serial.print("    H4 (mA)= ");  Serial.print(i4, 1);}    Serial.print("\r\n");   }   Serial.print("\r\n");   Serial.print("\r\n");   while (Serial.available()) {  // while there are characters in the buffer, grab them all...     incomingByte = Serial.read();  // will not be -1     Serial.print("Incoming byte: "); Serial.print(incomingByte);     // Serial.print("    Delay interval:"); Serial.print(delayintvl);  Serial.print("\r\n");     if (incomingByte == 'h' || incomingByte == 'H'){       Serial.print("\r\n\r\nHelp:\r\n\r\n");       Serial.print("  +/= delay interval +/- 10mS\r\n");       Serial.print("  /- delay interval 20msec/1sec\r\n");       Serial.print("  l/L all rails low/high range in unison\r\n");       Serial.print("  q/w/e/r toggle display of rail 1/2/3/4\r\n");       Serial.print("  1/2/3/4 high range of rail 1/2/3/4\r\n");       Serial.print("  !/@/#/$ low range of rail 1/2/3/4\r\n");       Serial.print("  h print this help...\r\n");       Serial.print("\r\n");       delay(2000);       }     // change delay interval...     if (incomingByte == '+') delayintvl = delayintvl + 10;     if (incomingByte == '=') delayintvl = delayintvl - 10;     if (incomingByte == '_') delayintvl = 20;     if (incomingByte == '-') delayintvl = 1000;     if (delayintvl<1) delayintvl = 20;     // toggle low/high range of all rails in unison...     if (incomingByte == 'L') {       digitalWrite(LoHiEn1, LOW);       digitalWrite(LoHiEn2, LOW);       digitalWrite(LoHiEn3, LOW);       digitalWrite(LoHiEn4, LOW);       one = true; two = true; three = true; four = true;     }     if (incomingByte == 'l') {       digitalWrite(LoHiEn1, HIGH);       digitalWrite(LoHiEn2, HIGH);       digitalWrite(LoHiEn3, HIGH);       digitalWrite(LoHiEn4, HIGH);       one = false; two = false; three = false; four = false;     }     // still unimplemented, but for wakeup of target board...     if (incomingByte == 'w') digitalWrite(WakeUp, LOW);     if (incomingByte == 'W') digitalWrite(WakeUp, HIGH);     // toggle display of rail...     if (incomingByte == 'q') dispone = !dispone;     if (incomingByte == 'w') disptwo = !disptwo;     if (incomingByte == 'e') dispthree = !dispthree;     if (incomingByte == 'r') dispfour = !dispfour;     // change between high/low range..     if (incomingByte == '1') { digitalWrite(LoHiEn1, LOW);  one = true; }     if (incomingByte == '!') { digitalWrite(LoHiEn1, HIGH); one = false;}     if (incomingByte == '2') { digitalWrite(LoHiEn2, LOW);  two = true;}     if (incomingByte == '@') { digitalWrite(LoHiEn2, HIGH); two = false;}     if (incomingByte == '3') { digitalWrite(LoHiEn3, LOW);  three = true;}     if (incomingByte == '#') { digitalWrite(LoHiEn3, HIGH); three = false;}     if (incomingByte == '4') { digitalWrite(LoHiEn4, LOW);  four = true;}     if (incomingByte == '$') { digitalWrite(LoHiEn4, HIGH); four = false;}     }   // wait delayintvl mS after the last reading:   delay(delayintvl); }‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Future Work and Improvements Work on a "smart" sensor with a local Kinetis device (KL02Z or KL05Z) on the sensor board itself that has three separate sense amplifiers (one run/high current and two low) has begun. There are several advantages to having a microcontroller on each sensor board: All instrumented rails can be measured simultaneously The sampling rate can be increase over current generation's round robin Measured data is sent over I2C or UART, allowing arbitrary number of rails to be instrumented Each sensor board can provide all its shunt and gain info Sensor board can be used in isolation, i.e., without a master profiler board A GUI interface for the serial data output by the profiler would be really nice... Addditional Information 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 
View full article
Following docs(English or Chinese version) are also can be referred as a hand on guide. Freescale i.MX6 DRAM Port Application Guide-DDR3 飞思卡尔i.MX6平台DRAM接口高阶应用指导-DDR3篇 Please find i.Mx6DQSDL LPDDR2 Script Aid through below link. i.Mx6DQSDL LPDDR2 Script Aid Please find i.Mx6DQSDL DDR3 Script Aid through below link. i.Mx6DQSDL DDR3 Script Aid Please find i.MX6SX DDR3 Script Aid through below link.. i.MX6SX DDR3 Script Aid Any questions are welcome! Change History: 0.02 - Add total 1Gbit density supporting.
View full article
Multiple-Overlay (or Multi-Overlay) means several video playbacks on a single screen. In case multiple screens are needed, check the dual-display case GStreamer i.MX6 Multi-Display $ export VSALPHA=1 $ SAMPLE1=sample1.avi; SAMPLE2=sample2.avi; SAMPLE3=sample3.avi; SAMPLE4=sample4.avi; $ WIDTH=320; HEIGHT=240; SEP=20 Four displays (2x2) $gst-launch \ playbin2 uri=file://`pwd`/$SAMPLE1 video-sink="mfw_isink axis-top=0 axis-left=0   disp-width=$WIDTH disp-height=$HEIGHT" \ playbin2 uri=file://`pwd`/$SAMPLE2 video-sink="mfw_isink axis-top=0 axis-left=`expr $WIDTH + $SEP` disp-width=$WIDTH disp-height=$HEIGHT" \ playbin2 uri=file://`pwd`/$SAMPLE3 video-sink="mfw_isink axis-top=`expr $HEIGHT + $SEP` axis-left=0   disp-width=$WIDTH disp-height=$HEIGHT" \ playbin2 uri=file://`pwd`/$SAMPLE4 video-sink="mfw_isink axis-top=`expr $HEIGHT + $SEP` axis-left=`expr $WIDTH + $SEP` disp-width=$WIDTH disp-height=$HEIGHT" Basic rotation, (2 x 1, normal and inverted) gst-launch \ playbin2 uri=file://`pwd`/$SAMPLE1 video-sink="mfw_isink axis-top=0 axis-left=0   disp-width=$WIDTH disp-height=$HEIGHT rotation=0" \ playbin2 uri=file://`pwd`/$SAMPLE2 video-sink="mfw_isink axis-top=`expr $HEIGHT + $SEP` axis-left=0 disp-width=$WIDTH disp-height=$HEIGHT rotation=3"
View full article
Introduction This document describes the Spread Spectrum support for displays on i.MX 8QuadMax and i.MX 8QuadXPlus, specific for LVDS display. It describes the underlying HW function, how to enable it and the intended capability. The display controller (DC) subsystem on i.MX 8QuadMax and i.MX 8QuadXPlus uses an AVPLL to generate the reference clock for operation of the LVDS PHYs.  Enabling Spread Spectrum on the reference clock will result in the PHY interfaces being spread as well. This Spread Spectrum feature is controlled by the SCU firmware and can be enabled or disabled by configuring the board file of the SCU firmware porting kit. (The Spread Spectrum feature is added starting from SCFW porting kit V1.2.2 release which can be download from NXP web site “i.MX Software and Development Tool”.) The User Guide will include following content: 1. Introduction ............................................................................ 1 2. Configuration of the frequency modulation ......................... 2 3. Support in SCFW Porting Kit ............................................... 4 4. Modulation Characteristics ................................................... 4 5. Enablement Example ............................................................. 5 6. Revision History .................................................................... 7 For more information, please check the attachment "User Guide of Spread Spectrum for i.MX8QM_QXP Display.pdf".   Rev2.0 Update For SCFW Porting Kit V1.2.5 and later version, please check document "User Guide of Spread Spectrum for i.MX8QM_QXP Display 2.0.pdf" with updated algorithm. Rev2.1 Update For SCFW Porting Kit V1.2.10 and later version, please check document "User Guide of Spread Spectrum for i.MX8QM_QXP Display 2.1.pdf" with fspread value selection feature. Users can choose the percentage of frequency spread from following values: 0%, 0.4%, 1.0%, 1.4%, 2.0%.
View full article
In some cases it is desired to directly have progressive content available from a TV-IN interface through the V4L2 capture device. In the BSP, HW accelerated de-interlacing is only supported in the V4L2 output stream. Below is a patch created against a rather old BSP version that adds support for de-interlaced V4L2 capture. The patch might need to be adapted to newer BSPs, However, the logic and functionality is there and should shorten the development time. This patch adds another input device to the V4L2 framework that can be selected to perform the deinterlacing on the way to memory. The selection is done by passing the index “2” as an argument to the VIDIOC_S_INPUT  V4L2 ioctl. Attached is also a modified the tvin unit test to give an example of how to use the new driver. An example sequence for running the test is as follows: modprobe mxc_v4l2_capture ./mxc_v4l2_tvin_vdi.out -ow 720 -oh 480 -ol 10 -ot 20 -f YU12 Some key things to note: This driver does not support resize or color space conversion on the way to memory. The requested format and size should match what can be provided directly by the sensor. The driver was tested on a Sabre AI Rev A board running Linux 12.02. This code is not an official delivery and as such no guarantee of support for this code is provided by Freescale.
View full article
Brief introduction on i.MX Android
View full article
1.  Software change for Certification Test Compared to standard Linux/Android release, you may need to do below software changes to implement the certification tests, it is applicable from imx_3.10.31_1.1.0 Linux BSP GA release, for the release before that, user may need to apply the related patches before doing below things, and some examples may be different for former releases, the user needs to change accordingly. See the detailed information in this document “How to do USB Compliance Test for 3.10.y kernel”. And there is also a link describes the patch for USB Certification Test: Patch to make i.MX6DQ USB to support test modes for certification test 2. I.MX6 series USB Certification Guide http://cache.freescale.com/files/microcontrollers/doc/user_guide/IMXUSBCGUG.pdf Include the descriptions of all the Certification Test requirements, equipment, procedures for I.MX6 series. For example, Host/Device High Speed Eye Diagram Test(眼图测试).   3. Description of USBCertification related Registers AN4589 Configuring USB on i.MX 6 Series Processors http://cache.freescale.com/files/32bit/doc/app_note/AN4589.pdf   4. I.MX6Q/I.MX6DL/I.MX6SL/ I.MX6SX Certification Reports, see attachments   5. Checklist and TPL, see attachments. Original Attachment has been moved to: I.MX6SX-Checklist-and-TPL.zip
View full article