Q: Looking at the datasheet, why a 14.7KOhm pulldown and a 4.7KOhm pullup must be used? When useing 4.7KOhm resistors in series from an MCU to control the boot pins, pull up is ok, but pull down is not. The EIM boot pins only see 4.7KOhm and not 14.7KOhm as recommended in the design guide. How did we determine those resistor values? at boot there is a pull-up of 100KOhm in the pad if I understand well, 4.7KOhm would do the job as well as 14.7K. right? A: 4.7k will work fine for pull-up or pull-down. 10k pull-downs is to limit current drain while allowing use of simple SPST switches to configure boot-up. There are on-chip 100k pull resistors, so this limits max resistor size. This document was generated from the following discussion: EIM boot resistor value

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

Play MPEG4 Video only gst-launch filesrc location=test.mpeg ! mfw_vpudecoder codec-type=std_mpeg4 ! mfw_v4lsink H.264 Video only gst-launch filesrc location=test.avi ! mfw_avidemuxer ! mfw_vpudecoder codec-type=std_avc ! mfw_v4lsink AVI(H264+MP3) gst-launch filesrc location=test.avi ! mfw_avidemuxer name=demux demux. !  mfw_vpudecoder \     codec-type=std_avc ! mfw_v4lsink demux. ! queue max-size-buffers=0 ! <mp3_decoder_plugin> ! alsasink MP4(H264+MP3) gst-launch filesrc location=test.mp4 ! mfw_mp4demuxer name=demux demux. ! \    mfw_vpudecoder codec-type=std_mpeg4 ! mfw_v4lsink demux. ! \    queue max-size-buffers=0 ! <mp3_decoder_plugin> ! alsasink <mp3_decoder_plugin> can be replaced by mad RAW Video Test gst-launch videotestsrc ! video/x-raw-yuv,format=\(fourcc\)I420 !  mfw_v4lsink

Sorry I can't find a place to share this input file. It is to reproduce the VPU JPEG decoder issue I reported in Corrupted MJPG decoding result with FSL 3.10.17 BSP on i.MX6Q VPU​

In order to improve the speed of compilation, VMWare Player 14.0 is installed on local hard disk, and Ubuntu 18.04 LTS is installed on a SSD with at least 500GB size and USB3.1 specification. When installing ubuntu 18.04 LTS to SSD, it should be allocated at least 350GB of disk space, because compiling this version of android requires a larger disk space. The following are detailed compilation steps: Part l Configuring Ubuntu 18.04 LTS 1. Installing Ubuntu 18.04 on VMplayer 14.0 After installation is done, root user should be set at first. # sudo passwd root Then follow these steps to configuration ubuntu 18.04 for environment of compiliation --Changing sources of ubuntu 18.04 mirror If you are Chinese users, you can do the step, which can improve your system performance. # sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak # sudo geit /etc/apt/source.list Comment I.MX customers outside China do not need to modify Ubuntu source list, or can modify it to local mirror site of Ubuntu 18.04, which can improve the speed of software upgrade.    Delet all sources and copy following lines here, Then save it and exit Changing ubuntu source deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic main restricted universe multiverse # deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic main restricted universe multiverse deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-updates main restricted universe multiverse # deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-updates main restricted universe multiverse deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-backports main restricted universe multiverse # deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-backports main restricted universe multiverse deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-security main restricted universe multiverse # deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-security main restricted universe multiverse # deb https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-proposed main restricted universe multiverse # deb-src https://mirrors.tuna.tsinghua.edu.cn/ubuntu/ bionic-proposed main restricted universe multiverse    Then running these 2 commands to update sources and packages    # sudo apt-get update    # sudo apt-get upgrade 2. Installing packages for compiliation Packages for compiliation # sudo apt-get install flex bison gperf build-essential zlib1g-dev lib32ncurses5-dev x11proto-core-dev libx11-dev lib32z1-dev libgl1-mesa-dev tofrodos python-markdown libxml2-utils xsltproc # sudo apt-get install uuid-dev:i386 liblzo2-dev:i386 gcc-multilib g++-multilib subversion openssh-server openssh-client uuid uuid-dev zlib1g-dev liblz-dev lzop liblzo2-2 liblzo2-dev git-core curl # sudo apt-get install u-boot-tools mtd-utils android-tools-fsutils openjdk-8-jdk device-tree-compiler aptitude libcurl4-openssl-dev nss-updatedb # sudo apt-get install chrpath texinfo gawk cpio diffstat gdisk m4 libz-dev libssl-dev Part 2 Compiling Android Q10.0.0_2.1.0 BSP 1. Downloading NXP source code for Android Q10.0.0_2.1.0    File name is imx-android-10.0.0_2.1.0.tar.gz.    Copy the file to ~/, and decompress it.    # cd ~/    # tar zxvf ./imx-android-10.0.0_2.1.0.tar.gz    Then “imx-android-10.0.0_2.1.0” directory is created at ~/, now run the command to download android source code. # source ./imx-android-10.0.0_2.1.0/imx_android_setup.sh Comment imx_android_setup.sh is a script file, which includes all steps needed by the environment of android Q10.0.0_2.1.0 BSP. If network environment is enough good, several hours later, it will be done. 2. Compiling Android Q10.0.0_2.1.0 Referring to steps in Android_User's_Guide.pdf, We summaries steps for compilation here: (1) Preparing cross-compile tool chain    In Android_User's_Guide.pdf, 2 kinds of tool chain are recommended for users. --- gcc-arm-8.3-2019.03-x86_64-aarch64-elf.tar.xz --- gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu.tar.xz    Users can select one of them, and then decompress it to /opt/ directory. On how to download them or more details, see Android_User's_Guide.pdf, page 3. Here we will use gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu.tar.xz as tool chain. (2) Beginning to Compile Android Q10.0.0_2.1.0 BSP    Since this version of Android BSP requires high memory capacity when compiling, if the memory configuration of the virtual machine is incorrect, it is very likely to cause the compilation to fail. The following is a list of variable tests for user reference: # cd android_build # export AARCH64_GCC_CROSS_COMPILE=/opt/gcc-arm-8.3-2019.03-x86_64-aarch64-linux-gnu/bin/aarch64-linux-gnu- # source build/envsetup.sh # lunch evk_8mp-userdebug # ./imx-make.sh -j2 2>&1 | tee build-log.txt Part 3 Errors During Compilation 1. Allocating 8GB Memory For VMware Player # ./imx-make.sh -j1 2>&1 | tee build-log.txt 2. Allocating 12GB Memory For VMware Player # ./imx-make.sh -j4 2>&1 | tee build-log.txt # ./imx-make.sh -j4 2>&1 | tee build-log.txt (Run it again) # ./imx-make.sh -j4 2>&1 | tee build-log.txt (Run it again)       So if we use 4 thread to compile BSP, command for compilation will have to be run for 3 times. NXP TIC Team Weidong Sun 2020/4/30

imx7 supports TRULY-WVGA-TFT3P5581E display, the connector is J30, which is a connector on the imx7d board, normally, one can find the part number from BOM file, but imx7 Sabre-SDB board  BOM file missed this information. got connector information from expert team as below: The connector manufacture’s part number is: DF40C-24DS-0.4V(51)   For more detailed information about sabre board information information is available from nxp.com in the Design files for i.MX7Dual   For data sheet of this, which is under NDA, if you need it, pls create a salesforce case to get this, I couldn’t post this on public community.

U-boot expects uImage format for the kernel image. In order to LTIB generate a uImage file: $ export SYSCFG_KTARG=uImage $ ./ltib -p kernel Setup in U-Boot the kernel bootargs: u-boot> setenv bootargs noinitrd console=ttymxc0,115200 init=/linuxrc root=/dev/nfs nfsroot=10.29.244.27:/tftpboot/rootfs ip=dhcp Change 10.29.244.27 to your host IP. The procedure above is needed when default bootloader used by ltib was redboot. In some ltib releases (before 2010) default bootloader is u-boot. In this case, ltib will create uImage by default

The i.MX6 Multi-Mode DDR Controller (MMDC) has profiling capabilities to monitor the operation of the controller. The profiling capability counts certain events related to a specified AXI-ID during a profiling period. The events that can be counted are: The number of read accesses during the profiling period (MMDCx_MADPSR2[RD_ACC_COUNT] register field) The number of write accesses during the profiling period (MMDCx_MADPSR3[WR_ACC_COUNT] register field) The number of bytes read during the profiling period (MMDCx_MADPSR4[RD_BYTES_COUNT] register field) The number of bytes written during the profiling period (MMDCx_MADPSR5[WR_BYTES_COUNT] register field) The number of MMDC clock cycles during which the MMDC state machine is busy (MMDCx_MADPSR1[BUSY_COUNT] register field) BUSY_COUNT is the number of MMDC clock cycles during the profiling period in which the MMDC state machine is not idle. So this is the time the MMDC spends doing any activity, not just read or write data transfers. The MMDC state machine is active whenever there are any read or write requests in the read and write FIFOs. The MMDC is active during many operations that are not reading or writing data such as arbitration of requests, control cycles, bank open/close, etc. So BUSY_COUNT represents the number of cycles when the controller is busy, not just the number of cycles when the external bus is busy. The number of bytes read and bytes written can be used to determine data throughput and the BUSY_COUNT can be used to determine what part of the time the controller is active/idle. Together these can be used to determine the controller efficiency for a particular application. For detailed information, see the "MMDC profiling" section of the MMDC chapter in the reference manual for the SoC being used.

Q: In mfgtool release 1.0.0 I, "Support only Cortex-A5 as primary boot core (Cortex-M4 boot is not supported on this release)." When will a version supporting M4 boot first be available? A: Mfg tool is based on it's counterpart, the ROM code. Rom code is for the A5 and not for the M4 as a matter of fact if you boot with the M4 and the device doesn't enumerate on the USB port at all then you know why and the MfgTool won't be able to do anything about it. Currently there no plans to provide a MfgTool version that supports boot from M4 core. Customers can modify the exisiting code to make it work with M4 as primary core. Booting from USB with the M4 core should work. The image that is booted must be for execution on M4 (thumb mode). MfgTool uses u-boot and a micro linux kernel to download images and program memories. This Linux can only run on the A5 core. To make it work with the M4 core as primary, it should be sufficient to add some code to the exisiting A5 images. Code will execute on M4 and start the A5 at the proper address as if it is booted from the A5.

Encode From YUV to H.264 gst-launch-0.10 filesrc location=file_in.yuv blocksize=w*h*1.5 ! \ mfw_vpuencoder codec type=std_avc framerate=fr ! filesink location=file_out.mpg Where: file_in.yuv: is the input file, a raw file. w*h*1.5: is the blocksize, it's calculated from input file dimensions: width * height * 1.5 mfw_vpuencoder: is the encoder with hardware acceleration for iMX27 std_avc: chooses the codec type for output file fr: indicates the framerate in that input file was created file_out.mpg: is the output file encoded in H.264 From Camera to H.264 gst-launch-0.10 mfw_v4lsrc ! mfw_vpuencoder codec-type=std_avc \ width=176 height=144 framerate=25 ! filesink location=test.video

When flashing a Linux System on a SD card using the script mk_mx28_sd on a Ubuntu 12.04 host, one needs to modify it so partitions are created correctly.  Just follow these steps on the console: $ cd $SDK/L2.6.35_10.12.01_SDK_scripts $ cat > first_partition_sector.patch << EOF diff -Naur a/mk_mx28_sd b/mk_mx28_sd --- a/mk_mx28_sd        2010-10-06 09:47:42.000000000 -0500 +++ b/mk_mx28_sd        2012-11-30 13:38:34.508199154 -0600 @@ -178,7 +178,7 @@ n p 1 -1 +2048 +32M t b EOF $ patch -p1 < first_partition_sector.patch then, you can run the mk_mx28_sd command again with the device as parameter                $ cd $LIB $ export PATH=$PATH:$SDK/L2.6.35_10.12.01_SDK_scripts $ mk_mx28_sd /dev/$SDX

The native Yocto not support chinese, so need to add chinese font . The first step should download Chinese font  files such as  MSYHMONO.ttf and DroidSansFallback.ttf.Then copy fonts files to /usr/share/fonts/truetype and run command  fc-cache .update font cache. use fc-list :lang=zh can see which Chinese fonts are installed:          /usr/share/fonts/truetype/MSYHMONO.ttf: Microsoft YaHei Mono:style=Regular          /usr/share/fonts/truetype/DroidSansFallbackFull.ttf: Droid Sans Fallback:style=Regular The secend step is to change default fonts. In weston-terminal.c we can see:           3119   weston_config_section_get_string(s, "font", &option_font, "mono");           3120   weston_config_section_get_int(s, "font-size", &option_font_size, 14);  weston-terminal default use mono font.Just to modify /etc/fonts/fonts.conf           <edit name="family" mode="assign" binding="same">                       <string>monospace</string> to   <string>Microsoft YaHei Mono</string> or <string>Droid Sans Fallback</string> could display Chinese character   But it have some problem such like as :   the left use Microsoft YaHei Mono font the Chinese character is overlapping ,the right use Droid Sans Fallback font is en-font could not display. If you have a better way to welcome a message！

The SNVS LDO output (VDD_SNVS_CAP) requires an external capacitor. Freescale's updated recommendation is that this should be a single 0.22 uF capacitor. Freescale is working to get documents in alignment. As of Feb 2013, some documents (such as schematics or user guides) show a single 0.22 uF capacitor, others do not.

This is a hack to support programming EEPROM I2C devices for MX28 boot. See post at: Re: mx28 boot issues with SSP (SD card) *** USE AT YOUR OWN RISK ***

This document provides steps to perform the system upgrade/OTA update for Android on i.MX platforms. Compile the Android images and generate an OTA Package: source build/envsetup.sh lunch sabresd_6dq-userdebug make -j4 make otapackage You can find your OTA package in the below path: ls out/target/product/sabresd_6dq/sabresd_6dq-ota-<xxx>.zip Copy the above OTA zip package to the device in sdcard using adb push adb push out/target/product/sabresd_6dq/sabresd_6dq-ota-<xxx>.zip /sdcard Move the package from sdcard to the location: /cache/update.zip Make the directory and perform the below steps on the device: mkdir -p /cache/recovery touch /cache/recovery/command echo "--update_package=/cache/update.zip" > /cache/recovery/command reboot recovery The recovery automatically applies the command and installs this update package. Note: In this document, the setup is for the i.MX6Q SABRESD Board. So, PathName and OTA package name subject to change based on target device compilation.

current imx6 bsp, not only ltib but also yocto couldn't support subtitle. now we have two solution to support subtitle on yocto, 1)one is extract the subtitle, then draw the subtitle on the video by UI, which is supported by the imxplayer. this solution is using QT by imxplayer, so if you build yocto, should choose QT as target. basicly, aiurdemux send the text to the QT by appsink, then QT draw the text on the UI layer. when build the yocot, pls using the command as below: " bitbake fsl-image-qt5" copy the font libary to the /usr/lib/fonts, then when you play the imxplayer, choose the font you need. 2)another one is blending the subtitle on the video buffer by gstreamer, then output with video enable gst pango lib in gstreamer1.0-plugins-base change playbin flag to disable native video flag basetextoverlay apply patch http://cgit.freedesktop.org/gstreamer/gst-plugins-base/commit/ext/pango/gstbasetextoverlay.c?id=267a8c24af4f02ba6f3075bd589d3c5d1dc826e9 use following command line gst-launch-1.0 playbin flags=0x17 uri=file://$VIDEO_FILE suburi=file://$SUBTITLE_FILE

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

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

Installing U-Boot on i.MX51EVK using BDI3000 Unlike older i.MX processor you don't need to select CONFIG_SKIP_LOWLEVEL_INIT because U-Boot lowlevel for i.MX51 doesn't reconfigure RAM memory. It is configured on DCD table. Copy u-boot.bin to /tftpboot because BDI3000 will load it from there. Connect the serial console cable on your i.MX51EVK board and connect to it using minicom. Connect to your BDI3000 through telnet and execute these commands: FSL-iMX51> load 0x97800000 u-boot.bin Loading u-boot.bin , please wait .... Loading program file passed FSL-iMX51> rm pc 0x97800000 FSL-iMX51> go When you execute the last command (“go”) you will see U-Boot starting on serial console.