Dumping the pipeline elements into a image file # On target, run the pipeline $ export GST_DEBUG_DUMP_DOT_DIR=<folder where dot files are created> $ gst-launch playbin2 uri=file://${avi} $ # Move the .dot files to a host machine (scp, etc) # On Host dot <dot file> -Tpng -o out.png # dot command is part the the graphviz package Querying which elements are being used on a gst-launch command GST_DEBUG=GST_ELEMENT_FACTORY:3 gst-launch playbin2 uri=file://`pwd`/<media file> Interrupting a gst-launch process running in the background kill -INT $PID # where $PID is the process ID Using only SW codecs # Backup and remove $ find /usr/lib/gstreamer-0.10 -name "libmfw*" | grep -v sink | xargs tar cvf /libmfw_gst.tar $ find /usr/lib/gstreamer-0.10 -name "libmfw*" | grep -v sink | xargs rm # Run your pipeline. This time SW codecs are used $ gst-launch playbin2 uri=file://`pwd`/media_file # To 'install' FSL plugins again, just untar the file $ cd / && tar xvf libmfw_gst.tar && cd - # then run your pipeline. This time HW codecs are used $ gst-launch playbin2 uri=file://`pwd`/media_file

If someone wants to use the OpenGL ES 2.0 extension "GL_OES_vertex_array_object", the macro "GL_GLEXT_PROTOTYPES" must be defined in his program first. Then he can get the extension program location by calling the API eglGetProcAddress.  Here is an example to use this extension. #define GL_GLEXT_PROTOTYPES PFNGLGENVERTEXARRAYSOESPROC glGenVertexArraysOESv; PFNGLBINDVERTEXARRAYOESPROC glBindVertexArrayOESv; PFNGLDELETEVERTEXARRAYSOESPROC glDeleteVertexArraysOESv; glGenVertexArraysOESv = (PFNGLGENVERTEXARRAYSOESPROC)eglGetProcAddress ( "glGenVertexArraysOES" ); glBindVertexArrayOESv = (PFNGLBINDVERTEXARRAYOESPROC)eglGetProcAddress ( "glBindVertexArrayOES" ); glDeleteVertexArraysOESv = (PFNGLDELETEVERTEXARRAYSOESPROC)eglGetProcAddress ( "glDeleteVertexArraysOES" ); After these steps, the new alias glGenVertexArraysOESv, glBindVertexArrayOESv, glDeleteVertexArraysOESv can be use to call the VAO operation function in OpenGL ES 2.0 extensions.

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

Step 1: Build r13.4.1         make         /* Store images file for MFGTool use */         make dist    /* Get ota_1.zip, and target_files_1.zip at out/dist, store them in a dedicated directory, for example .../release-1 */ Step 2: Modify any files in source code base; Step 3: make dist    /* Get ota_2.zip, and target_files_2.zip at out/dist, store them in a dedicated directory, for example .../release-2 */ Step 4: MFGTool flash release-1 images; Step 5: cp ota_2.zip to SD; Step 6: start board, then execute following commands under serial terminal;         cp /sdcard/ota_2.zip /cache/ota_2.zip         mkdir /cache/recovery         echo --update_package=/cache/ota_2.zip > /cache/recovery/command         sync         reboot recovery         Then you can see the upgrade successful. Step 7: MFGTool flash release-1 images; Step 8: ./build/tools/releasetools/ota_from_target_files -i .../release-1/target_files_1.zip .../release-2/target_files_2.zip ./diff_from_1_to_2.zip Step 9: cp diff_from_1_to_2.zip to SD; Step10: start board, then execute following commands under serial terminal;         cp /sdcard/diff_from_1_to_2.zip /cache/diff.zip         mkdir /cache/recovery         echo --update_package=/cache/diff.zip > /cache/recovery/command         sync         reboot recovery

To use Android GDB for native code, take mediaserver as an example. Setup on board. adb push prebuilt/android-arm/gdbserver/gdbserver system/bin/ adb shell ps adb shell /system/bin/gdbserver :5039 --attach <PID> & Setup on host. source build/env.sh adb forward tcp:5039 tcp:5039 gdbclient mediaserver b createPlayer c

Issue Description When running Android R10.4 on MX51 BBG, the system can not resume sometimes by following the test steps: 1) Enable CLAA-WVGA lcd panel - single display. 2) Play a video in Gallery. 3) Press power key to suspend the system. 4) Press power key to resume the system. 5) Do 3) and 4) continuously. Debug Details When adding the following debug information into vpu_resume function in file drivers/mxc/vpu/mxc_vpu.c, the system gets hang into while loop with the log "VPU Blocking 1**************": static int vpu_resume(struct platform_device *pdev) {         int i;                 WRITE_REG(BITVAL_PIC_RUN, BIT_INT_ENABLE);                 WRITE_REG(0x1, BIT_BUSY_FLAG);                 WRITE_REG(0x1, BIT_CODE_RUN);                 while (READ_REG(BIT_BUSY_FLAG)) {                           printk("VPU Blocking 1**************\r\n");                }; } Root Cause In some use cases,  VPU power gating didn't happen after vpu_suspend() returned successfully because some other devices refused to suspend or other reasons. So vpu_resume() ran FW init code when VPU was idle instead of power off, which could keep BIT_BUSY_FLAG always be 1. Solution In vpu_resume(), if VPU PC is not 0, which means VPU is still running, skip running FW init code. See attached patch based on R10.4.

A simple Linux kernel module to react on GPIO-generated interrupts

MX6X_Uboot_V1-20130910.doc: 3.0.35: 3.0.35

imx53 DDR stress tester V0.042

HI, I want to build an Ubuntu Linux operating system with LTIB, but from the user guide the host system is Ubuntu 9.04, but we can't use 'apt-get install' any package due to there are no source lists. What should we do next? Thank you!

Seeing a block diagram in IMX6SLRM 1.5.1, it looks like i.MXSL has Touch Panel Control. Is there interfaces for touch panel  in IMX6SL? Otherwise if I build HW using ADC or GPIO, can I be provided some SW drivers? Regards. The i.MX6 SL does not have embedded touch / ADC interface, sorry. Have a great day, Yuri ----------------------------------------------------------------------------------------------------------------------- Note: If this post answers your question, please click the Correct Answer button. Thank you! ----------------------------------------------------------------------------------------------------------------------- This document was generated from the following discussion: 

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-341996 

Software Update and Recovery The information reproduced above is from Android User Guide R10.2, found into Android release package. It is possible to format the /data and /cache partitions or update software based on a update script using recovery mode as follows: Prepare for all Android source code that assumed to be saved in ~/myandroid directory. Prepare for ADB over USB. make sure that ADB over USB is ok. USB cable is connected. Refer to i.MX51 Android ADB over USB section for more information. Connect the UART to the PC and open a terminal to check for printed messages Enter the recovery by manual for imx51_BBG board:       setenv bootargs_android_recovery 'setenv bootargs ${bootargs} init=/init root=/dev/mmcblk0p4 rootfs=ext4 di1_primary'       setenv bootcmd_android_recovery 'run bootargs_base bootargs_android_recovery;mmc read 0 ${loadaddr} 0x800 0x2000;bootm'       run bootcmd_android_recovery For imx53_SMD board:       setenv bootargs_android_recovery 'setenv bootargs ${bootargs} init=/init root=/dev/mmcblk0p4 rootfs=ext4'       setenv bootcmd_android_recovery 'run bootargs_base bootargs_android_recovery;mmc read 0 ${loadaddr} 0x800 0x2000;bootm'       run bootcmd_android_recovery When system has completed bootup,  You will see this screen: You can press "MENU" "HOME" or "F1" (by USB keyboard, for developer)" going to the text menu like this: Select the required option using the direction keys on the keypad or keyboard. Apply sdcard:update.zip, you may update the software from update.zip as shown in the following example: Copy this directory from android source code myandroid/bootable/recovery/etc to a tempepory directory, such as ~/recovery. cd ~/recovery and remove init.rc from this directory. Edit ./META-INF/com/google/android/updater-script according to the required commands. for example, in order to format /system partition and use update.zip to update system partition, copy whole the entire content directory to system partition, all commands are found in ~/myandroid/bootable/recovery/update/install.c You must notice, when your signing the zip package, it will lose ALL of the permission information, you need to set the right permission in the script. You can find the example in ./META-INF/com/google/android/updater-script Copy update-binary, Copy out/target/product/YOU_PRODUCT/system/bin/updater to ~/recovery/META-INF/com/google/android/update-binary Create a directory called system and copy some files you would like to update to ./system. Create a directory called res to save the public key of your system.         fsl@fsl-desktop:~/recovery$ mkdir res         fsl@fsl-desktop:~/recovery$ ~/myandroid/out/host/linux-x86/framework/dumpkey.jar ~/myandroid/build/target/product/security/testkey.x509.pem > res/keys Create a package called recovery.zip using the zip command         fsl@fsl-desktop:~/recovery$zip recovery.zip -r ./META-INF ./system ./res recovery.zip is located in the current directory. Then create a digital signature for recovery.zip package as follows.         fsl@fsl-desktop:~/recovery$ cd ~/myandroid         fsl@fsl-desktop:~/myandroid$ make signapk         fsl@fsl-desktop:~/myandroid$ cd ~/recovery         fsl@fsl-desktop:~/recovery$ java -jar ~/myandroid/out/host/linux-x86/framework/signapk.jar -w ~/myandroid/build/target/product/security/testkey.x509.pem ~/myandroid/build/target/product/security/testkey.pk8 recovery.zip recovery_signed.zip recovery_signed.zip is located in the current directory. Copy it to the SD card using ADB         fsl@fsl-desktop:~/recovery$ adb push recovery_signed.zip /sdcard/update.zip update.zip is completed and the system is updated based on the commands in the update-script. Check for error messages on the LCD. Wipe data/factory reset. /data and /cache partitions are formatted. Wipe cache partition. /cache partition is formatted. Reboot the system.

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

The patch is based on jb4.3_1.1.1-ga_rc2. Merge some commits from kitkat.

Overview This document introduces how to setup i.MX6Dual/Quad and i.MX6Solo/DualLite Linux software for PCIe compliance test. Software Baselines i.MX6Dual/Quad: Linux BSP L2.6.35_1.0.0 i.MX6Solo/DualLite: Linux BSP L2.6.35_2.0.0 Software Changes To enable PCIe compliance test, PCIe software driver should not turn off PCIe clock and power in the tests. So the following changes are required: diff --git a/arch/arm/mach-mx6/pcie.c b/arch/arm/mach-mx6/pcie.c index 26d26f2..ad71085 100644 --- a/arch/arm/mach-mx6/pcie.c +++ b/arch/arm/mach-mx6/pcie.c @@ -801,6 +801,7 @@ static void __init add_pcie_port(void __iomem *base, void __iomem *dbi_base,      } else {          pr_info("IMX PCIe port: link down!\n"); +#if 0          /* Release the clocks, and disable the power */          pcie_clk = clk_get(NULL, "pcie_clk");          if (IS_ERR(pcie_clk)) @@ -820,6 +821,7 @@ static void __init add_pcie_port(void __iomem *base, void __iomem *dbi_base,          imx_pcie_clrset(IOMUXC_GPR1_TEST_POWERDOWN, 1 << 18,                  IOMUXC_GPR1); +#endif      } } Software Build Integrate the patch to the baseline code and recompile the kernel by following the instructions in Linux BSP user guide. Before recompile, please ensure the following configuration is enabled by selecting " System Type -> Freescale MXC Implementations -> PCI Express support" as "*": # MX6 Options: # CONFIG_IMX_PCIE=y

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-344779 

i.MX6 Quad/6Dual/6SoloLite Errata ERR006282: ROM code uses non-reset PFDs to generate clocks which may lead to random boot failures This PDF contains information about an issue affecting i.MX 6Quad/6Dual/6SoloLite Phase Fractional Dividers (PFDs) and boot. This erratum will be included in the next update of the i.MX6x Silicon Errata documentation but is being provided here for reference until then.