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

UPDATE: Note that this document describes eIQ Machine Learning Software for the NXP L4.14 BSP release. Beginning with the L4.19 BSP, eIQ Software is pre-integrated in the BSP release and this document is no longer necessary or being maintained. For more information on eIQ Software in these releases (L4.19, L5.4, etc), please refer to the "NXP eIQ Machine Learning" chapter in the Linux User Guide for that specific release.  Original Post: eIQ Machine Learning Software for iMX Linux 4.14.y kernel series is available now. The NXP eIQ™ Machine Learning Software Development Environment enables the use of ML algorithms on NXP MCUs, i.MX RT crossover processors, and i.MX family SoCs. eIQ software includes inference engines, neural network compilers, and optimized libraries and leverages open source technologies. eIQ is fully integrated into our MCUXpresso SDK and Yocto development environments, allowing you to develop complete system-level applications with ease. Source download, build and installation Please refer to document NXP eIQ(TM) Machine Learning Enablement (UM11226.pdf) for detailed instructions on how to download, build and install eIQ software on your platform. Sample applications To help get you started right away we've posted numerous howtos and sample applications right here in the community. Please refer to eIQ Sample Apps - Overview. Supported platforms eIQ Machine learning software for i.MX Linux 4.14.y supports the L4.14.78-1.0.0 and L4.14.98-2.0.0 GA releases running on i.MX 8 Series Applications Processors. For more information on artificial intelligence, machine learning and eIQ Software please visit AI & Machine Learning | NXP.

Extending to the impact produced by being the First to release WEC7 on i.MX6 Development Platform, iWave Systems adds yet another accomplishment by announcing the availability of Windows Embedded Compact 7 (WEC7) reference BSP for Freescale’s i.MX6x SABRE SDB/SDP. The Freescale’s i.MX6x SABRE SDB/SDP Platform is powered with Freescale’s i.MX6 Quad/Dual Lite 1GHz, MMPF0100 Freescale PMIC. The WEC7 BSP release supports SATA II, Standard SD/SDIO, Gigabit Ethernet, LVDS, Touch Panel, HDMI port and also necessary hardware codecs supported by the CPU. Debugging tools like KITL and CETK are also supported. All the latest features that WEC7 offers such as Silverlight 3.0, MPEG-4 HD, Expression Blend, Active Sync and also Adobe Flash10.1 are made available.                                                                                                                                                                 Benefits: WEC7 Source code can be easily customized with respect to the target hardware platform Simple and low cost integration for any Freescale i.MX6x based platform       Quick time to market Highlights: Ideal for Quick Proof of concept (POC) development Shortens up to 60% of the new product development life cycle                                       Quick customization services in a very short period Features: Standard Features: i.MX6 Quad/Dual Lite 1GHz CPU MMPF0100 Freescale PMIC 1 GB DDR3 RAM Serial console SD boot SATA II SD/SDIO HDMI Gigabit Ethernet USB OTG Audio LVDS display Touch Optional Features: PCIe Camera CAN GPS VPU (HD Coding and Decoding supported) GPU (Open GL, Open VG, Direct3DM and DirectDraw) Target Applications: Automotive IVI Telematics Interactive POS Industrial HMI Medical Click Here for more details on WEC7 BSP Support for Freescale's i.MX6x Sabre SDB/SDP by iWave Click Here for more details on WEC7 BSP Support for various other i.MX processors

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

Overview: This document is written for Freescale customers who have Freescale AC3 release packages (excluded package). (If you did not have the AC3 release package, you can disregard this document.) Freescale OMX Player in Android release supports audio track selection when playing files with multiple audio tracks. However, most customers don't use this enhanced API to select the audio track even if current audio codec is not supported. To avoid a soundless output when partial audio track can be played, this document provides the method to select the available audio track automatically to play. The patch in this document is not included in our current release because it did not match with our track selection rule - play the first track. If you have any idea with this issue, feel free to add comments into this document. Issue description: Software: R13.4-GA or R13.4.1 Android releases Hardware: MX6Dual/Quad SabreSD board Test source: 1.mkv Test Step: 1. Lunch Gallery from main menu. 2. Play the video And you can see the watch the video without any sound Root Reason: The file has 2 audio track DTS & AC3: audio track 1 is DTS and track 2 is AC3. OMX Player will choose the first audio track to play as default audio track, which is DTS audio. However, the software only supports the AC3 audio codec, so it could not set up audio decoder for DTS track. If we choose to play the AC3 track, sounds could be heard. How to fix: The audio track index is set in GMPlayer::LoadParser(). You can get audio format to check whether it is supported by decoder. Please see the patch audio_track_slection.diff

i.MX27 PDK Board Flashing This tutorial teaches how to flash bootloader using ATK. To flash kernel and root file system, follow the directions: IMX27 PDK NAND Flashing RedBoot. Using ATK ATK (Advanced Toolkit) is a Windows software for programming the flash memory of i.MX boards. This section will describe the procedure to erase the flash memory and program the bootloader. 1 - Connect a serial cable between PC and i.MX board. 2 - Some hardware configurations (switches) must be done to flash the board. Set red and cream switches as below: Switch SW5 -> 00000 Switch SW4 -> 10000001 Installing ATK on Linux Download ATK: Download. Extract ATK: # unzip ATK_1_41_STD_installer.zip Execute the default install process: # wine SETUP.EXE Get mfc42.dll and msvcp60.dll from a Windows Machine (C:\Windows\System32) and copy to wine system32 (/root/.wine/drive_c/windows/system32) Run ATK: # wine ADSToolkit_std.exe Next Step To flash kernel and root file system, follow the directions: IMX27 PDK NAND Flashing RedBoot. PS: On SW5 and SW4, "1" means the keys selected towards the edge of the board. 3 - Run ATK by clicking Start -> Programs -> AdvancedToolKit -> AdvancedToolKit       Set the options:    Device memory -> DDR; Custom Initial File -> (keep it unmarked)    Communication Channel -> Serial Port (Usually COM1) 4 - Click on Flash Tools to erase, program or dump the the flash memory and click GO. Flash Erasing 1 - To erase Flash memory, select the parameters as shown in the figure below: 2 - Turn on the board and press Erase. 3 - ATK shows this message when flash is erased Flash Programming The next step is to program the bootloader image into the board's Flash following the steps below. 1 - Select the parameters as shown in the figure below and press Program. The bootloader binary image file can be found into your Board Support Package Set Program, NAND, Address: 0x00000000 2 - Add it on Image File field and press Program. 3 - Close ATK, turn off the board and set switch back as shown in the picture below. Installing ATK on Linux Download ATK: Download. Extract ATK: # unzip ATK_1_41_STD_installer.zip Execute the default install process: # wine SETUP.EXE Get mfc42.dll and msvcp60.dll from a Windows Machine (C:\Windows\System32) and copy to wine system32 (/root/.wine/drive_c/windows/system32) Run ATK: # wine ADSToolkit_std.exe Next Step To flash kernel and root file system, follow the directions: IMX27 PDK NAND Flashing RedBoot.

This documents describes how to add the NFC support to i.MX8M mini evk running Yocto. Hardware setup: The i.MX8M mini evk (see i.MX 8M Mini Evaluation Kit | NXP) featuring Raspberry Pi compliant connector, the OM5578/RPI PN7150 demo kit can be used to perform this porting (see NFC Development Kits for Arduino and more|NXP). However a small modification must be done because some of the signals required by PN7150 are not mapped to i.MX8M mini expansion connector pins. OM5578 IRQ signal must be mapped to Raspberry Pi connector pin #19 and OM5578 IRQ signal must be mapped to Raspberry Pi connector pin #21. See below a picture of the modification: Then, the two boards can fit together as shown in the picture below: Quick start using demo image: The demo image including support for PN7150, is based on i.MX Linux 4.14.78_1.0.0 BSP software release (see i.MX Software | NXP). Related documentation can be downloaded from here: https://www.nxp.com/webapp/Download?colCode=L4.14.78_1.0.0_LINUX_DOCS. Just flash the demo image (downloaded from here: https://www.nxp.com/lgfiles/updates/NFC/LINUX_L4-14-78_IMAGE_MX8MMEVK.zip) following guidelines from i.MX_Linux_User's_Guide document (part of L4.14.78_1.0.0_LINUX Documentation package mentioned above). Then in a terminal you can run the demo application included in the image executing the command:    # nfcDemoApp poll Approaching the NFC tag, provided as reference in the OM5578 demo kit, to the NFC Antenna will trigger such display: Adding PN7150 support to imx-linux-sumo release: Pre-condition is to have L4.14.78_1.0.0 release installed and already built as described in i.MX Yocto Project User's Guide (part of L4.14.78_1.0.0_LINUX Documentation package mentioned above) :     $ repo init -u https://source.codeaurora.org/external/imx/imx-manifest  -b imx-linux-sumo -m imx-4.14.78-1.0.0_ga.xml     $ repo sync     $ MACHINE=imx8mmevk DISTRO=fsl-imx-xwayland source fsl-setup-release.sh -b build_dir     $ bitbake fsl-image-validation-imx Then to add PN7150 support to your imx-linux-sumo environment, follow below step by step guidelines: In the sources directory, download the meta-nxp-nfc layer from https://github.com/NXPNFCLinux/meta-nxp-nfc     $ git clone https://github.com/NXPNFCLinux/meta-nxp-nfc.git  Define hardware connection between CPU and PN7150 in device-tree adding the following lines to file build_dir/tmp/work-shared/imx8mmevk/kernel-source/arch/arm64/boot/dts/freescale/fsl-imx8mm-evk.dts: @@ -227,6 +227,8 @@                         fsl,pins = <                                 MX8MM_IOMUXC_I2C3_SCL_I2C3_SCL                  0x400001c3                                 MX8MM_IOMUXC_I2C3_SDA_I2C3_SDA                  0x400001c3 +                               MX8MM_IOMUXC_ECSPI2_MOSI_GPIO5_IO11             0x41 +                               MX8MM_IOMUXC_ECSPI2_MISO_GPIO5_IO12             0x41                         >;                 };   @@ -747,6 +749,13 @@         pinctrl-0 = <&pinctrl_i2c3>;         status = "okay";   +       pn54x: pn54x@28 { +               compatible ="nxp,pn547"; +               reg = <0x28>; +               interrupt-gpios = <&gpio5 11 0>; +               enable-gpios = <&gpio5 12 0>; +       }; +         pca6416: gpio@20 {                 compatible = "ti,tca6416";                 reg = <0x20>; Add the meta-nxp-nfc layer to the build definition updating file build_dir/conf/bblayers.conf with: BBLAYERS += " ${BSPDIR}/sources/meta-nxp-nfc" Add the meta-nxp-nfc layer components to the image definition updating file build_dir/conf/local.conf with: IMAGE_INSTALL_append = " kernel-module-nxp-pn5xx nxp-nfc-bin " Re-build the linux kernel:     $ bitbake -f -c compile linux-imx && bitbake -f -c deploy linux-imx Build meta-nxp-nfc layer:     $ bitbake nxp-nfc Re-build the complete image to include the modifications:     $ bitbake fsl-image-validation-imx Then you can flash the updated image to your i.MX8M mini evk and run the demo application as described in above "Quick start using demo image" chapter. Reference: This porting have been done (demo image and instructions) following guidelines provided in AN11679_PN71xx_Linux_Software_Stack_Integration_Guidelines document.

After porting u-boot to your i.MX5x board you might want add it on LTIB menu, "Choose your board for u-boot" section. For this, edit ltib/config/platform/imx/main.lkc to add your board: Enter board on menu: comment "Choose your board for u-boot" choice prompt "board" default BOARD_MX51_BBG depends on PLATFORM = "imx51" help This menu will let you choose the board you use. ... + config BOARD_MX53_MYBOARD + bool "mx53_myboard" ... endchoice Add the "mx53_myboard_config" that matches your board configuration on the u-boot Makefile to PKG_U_BOOT_CONFIG_TYPE: config PKG_U_BOOT_CONFIG_TYPE   string   ... + default "mx53_myboard_config" if ( PLATFORM = "imx51" && BOARD_MX53_MYBOARD && !PKG_KERNEL_UPDATER )   ...

Quick Steps Four quick steps to build and flash a UBIFS image on i.MX35 NAND (K9LBG08U0D-PCB0), for information on how to you another memory, please see next section. Enable MTD_UBI and UBIFS_FS on kernel Create UBI image from rootfs (used for NFS) - ON PC mkfs.ubifs -v -r rootfs -m 2048 -e 258048 -c 966 -o ubifs.img ubinize -o ubi.img -m 2048 -p 256KiB -s 2048 ubinize.cfg Format NAND using UBI image - ON TARGET ubiformat -f ubi.img /dev/mtd8 Load UBI file system load -r -b 0x100000 zImage fis create -f 0x300000 kernel fis load kernel exec -c "noinitrd console=ttymxc0 115200 ubi.mtd=8 root=ubi0:rootfs rw rootfstype=ubifs ip=none" How To First of all, install mtd-utils on both target and host: Target: ./ltib -c Package list [*] mtd-utils Host sudo aptget install mtd-utils 1. Enable MTD_UBI and UBIFS_FS on kernel MTD_UBI -> Device Drivers     -> Memory Technology Device (MTD) support (MTD [=y])           -> UBI - Unsorted block images                   <*> Enable UBI                    (4096) UBI wear-leveling threshold (NEW)                    (1) Percentage of reserved eraseblocks for bad eraseblocks handling (NEW)                 < > MTD devices emulation driver (gluebi) (NEW)                    ** UBI debugging options **                    [ ] UBI debugging (NEW) UBIFS_FS -> File systems         ->Miscellaneous filesystems             <*> UBIFS file system support                 [ ] Extended attributes support (NEW)                 [ ] Advanced compression options (NEW)                 [ ] Enable debugging (NEW) 2. Create UBI image On TARGET Collect some information needed in order to create the UBI image according to your NAND device root@freescale \~$ cat /proc/mtd dev:   size   erasesize name mtd0: 00080000 00020000 "Bootloader" mtd1: 00400000 00020000 "nor.Kernel" mtd2: 01e00000 00020000 "nor.userfs" mtd3: 01c00000 00020000 "nor.rootfs" mtd4: 00003000 00020000 "FIS directory" mtd5: 02001000 00020000 "Redboot config" mtd6: 00300000 00040000 "nand.bootloader" mtd7: 00500000 00040000 "nand.kernel" mtd8: 10000000 00040000 "nand.rootfs" mtd9: 00800000 00040000 "nand.configure" mtd10: 6f000000 00040000 "nand.userfs" I will use mtd8, because I want the NAND rootfs MTD partition. More on [1] root@freescale ~$ ubiattach /dev/ubi_ctrl -m 8 UBI: attaching mtd8 to ubi0 UBI: physical eraseblock size:   262144 bytes (256 KiB) UBI: logical eraseblock size:    258048 bytes UBI: smallest flash I/O unit:    2048 UBI: VID header offset:          2048 (aligned 2048) UBI: data offset:                4096 UBI: empty MTD device detected UBI: create volume table (copy #1) UBI: create volume table (copy #2) UBI: attached mtd8 to ubi0 UBI: MTD device name:            "nand.rootfs" UBI: MTD device size:            256 MiB UBI: number of good PEBs:        979 UBI: number of bad PEBs:         45 UBI: max. allowed volumes:       128 UBI: wear-leveling threshold:    4096 UBI: number of internal volumes: 1 UBI: number of user volumes:     0 UBI: available PEBs:             966 UBI: total number of reserved PEBs: 13 UBI: number of PEBs reserved for bad PEB handling: 9 UBI: max/mean erase counter: 0/0 UBI: image sequence number: 0 UBI: background thread "ubi_bgt0d" started, PID 2098 UBI device number You will need: -p = physical eraseblock size = 256KiB -e = logical eraseblock size = 258048 -m = smallest flash I/O unit = 2048 -s = VID header offset = 2048 -c = available PEB = 966 Values only for iMX35 PDK NAND - K9LBG08U0D-PCB0 3. ON HOST - Now, create the images (two steps) You need to create ubinize.cfg file! ubinize.cfg [ubifs] mode=ubi image=ubifs.img vol_id=0 vol_size=237MiB vol_type=dynamic vol_name=rootfs vol_flags=autoresize $ mkfs.ubifs -v -r rootfs -m 2048 -e 258048 -c 966 -o ubifs.img mkfs.ubifs      root:                rootfs/      min_io_size:    2048      leb_size:         258048      max_leb_cnt:   966      output:            ubifs.img      jrn_size:          8388608      reserved:         0      compr:            lzo      keyhash:         r5      fanout:            8      orph_lebs:       1      super lebs:      1      master lebs:    2      log_lebs:         4      lpt_lebs:          2      orph_lebs:       1      main_lebs:       132      gc lebs:           1      index lebs:       2      leb_cnt:           142      UUID:              CC2057F9-B20F-46D1-A399-1FCA95DCAFF7 Success\! $ ubinize -o ubi.img -m 2048 -p 256KiB -s 2048 ubinize.cfg $ ls -lh u* -rw-r--r-- 1 daiane daiane 35M 2010-11-26 15:21 ubifs.img -rw-r--r-- 1 daiane daiane 36M 2010-11-26 15:22 ubi.img -rw-r--r-- 1 daiane daiane 113 2010-11-26 15:22 ubinize.cfg $ sudo cp ubi.img rootfs/home/ 4. Format NAND using UBI image - ON TARGET Turn on target (or reset it) and format MTD partition $ cd /home $ ubiformat -f ubi.img /dev/mtd8 5. Load UBI file system Reset and change redboot script: .. fis load kernel .. exec -c "noinitrd console=ttymxc0 115200 ubi.mtd=8 root=ubi0:rootfs rw rootfstype=ubifs ip=none"

Q: How to get the CSI BT656 without HSYNC/VSYNC working. The problem, is that all implemented driver in the BSP are using the external HSYNC/VSYNC synchronization signal. The SW designer is actually struggling to find the right way to generate the end of field active interrupt (end of frame). > mxc_v4l2_still.out I get an: > ERROR: v4l2 capture: mxc_v4l_read timeout counter 0 > > When using mxc_v4l2_capture.out or mxc_v4l2_tvin.out I get an: > ERROR: v4l2 capture: mxc_v4l_dqueue timeout enc_counter 0 > To help him implementing the driver, I need to get some insight on the IPUx_CSIn_CCIR_CODE_1/2/3 as it seems that the bit description 21 to 19 (CSI_STRT_FLD0_ACTV) is not described (same for all the multiple bit field in this register. Maybe it should match the ITU656, but here as well the driver examples does not match the bit description of the ITU standard. So my questions: IS it really possible to implement the BT656 with SAV / EAV and without external HSYNC/VSYNC? If yes, is it possible to review the IPUx_CSIn_CCIR_CODE_1/2/3 fields and communicate which parameter should be provided here? i.MX6Q A:      For no VSYNC and HSYNC case, in the sensor driver such as "linux-3.0.35\drivers\media\video\mxc\capture\adv7180.c", function ioctl_g_ifparm(), you should set p->u.bt656.bt_sync_correct to 0;      p->u.bt656.bt_sync_correct = 1; // It means external VSYNC and HSYNC will be used for SYNC.      p->u.bt656.bt_sync_correct = 0; // No external VSYNC and HSYNC, embedded EAV and SAV will be used for SYNC.      In iMX6 BSP, the CCIR related code is ready in "linux-3.0.35\drivers\mxc\ipu3\ipu_capture.c", function ipu_csi_init_interface(), no code modification was needed, that code was verified work.      For BT656 mode, your sensor driver such as adv7180, should also report correct parameters in function function ioctl_g_ifparm().      p->u.bt656.clock_curr = 0;  // This will tell linux-3.0.35\drivers\media\video\mxc\capture\mxc_v4l2_capture.c to use "IPU_CSI_CLK_MODE_CCIR656_INTERLACED" in function mxc_v4l2_s_param().      The current iMX6 BSP mxc_v4l2_capture.c driver doesn't support BT656 progressive mode, it only supports BT656 interlace mode. To support BT656 progressive mode, the customer should modify the code in mxc_v4l2_s_param(), let csi_param.clk_mode = IPU_CSI_CLK_MODE_CCIR656_PROGRESSIVE. This is exactly what they are doing, but still it doesn’t work. Actually, they see the code being executed following the right steps in the ipu_csi_init_interface() going through PAL 720x625 configuration. But still, they get the timeout! else if (cfg_param.clk_mode == IPU_CSI_CLK_MODE_CCIR656_INTERLACED) {       if (width == 720 && height == 625) {         /* PAL case */         /*         Field0BlankEnd = 0x6, Field0BlankStart = 0x2,         Field0ActiveEnd = 0x4, Field0ActiveStart = 0           */         ipu_csi_write(ipu, csi, 0x40596, CSI_CCIR_CODE_1);         /*         Field1BlankEnd = 0x7, Field1BlankStart = 0x3,         Field1ActiveEnd = 0x5, Field1ActiveStart = 0x1           */         ipu_csi_write(ipu, csi, 0xD07DF, CSI_CCIR_CODE_2);         ipu_csi_write(ipu, csi, 0xFF0000, CSI_CCIR_CODE_3); So, I believe the parameters are wrong. What could be missing. Can you review the driver? For me it looks like the adv example, except the bt_sync_correct=0, which is what we want. You can suggest the customer to capture the CSI data bus to check if there is correct output from sensor, such as EAV/SAV. For the "timeout" error, it always means there is no correct data on CSI data bus. This document was generated from the following discussion: CSI BT656

i.MX evaluation board can be a simple solution to program i.MX boards in a factory for instance. i.MX evaluation board are not for industrial usage, but you can find plenty of cheap i.MX insdustrial boards on the web. Here I am using an i.MX8QXP rev B0 MEK board and I will program an i.MX6Q SABRE SD board. The first step is to generate your image. Follow the documentation steps to generate the "validation" image. You will have to customize a little bit the local.conf file (in conf/local.conf) to have git, cmake, gcc and other missing package. edit local.conf and add the following lines at the end of the file: IMAGE_INSTALL_append = " git cmake htop packagegroup-core-buildessential xz p7zip rsync"‍‍‍‍‍ I have added rsync package in local, it can replace cp (copy) but with the --progress option you can see the copy progression. P7zip replace unzip for our images archives avaialable on nxp.com as unzip as issues with big files. then rebake your image: bitbake -k fsl-image-validation-imx‍‍‍‍‍ When it is done, go in tmp/deploy/image/<your image generated> and use uuu to program your board (I use a sd card; thus I can increase the partition esily): sudo ./uuu -b sd_all imx-boot-imx8qxpmek-sd.bin-flash fsl-image-validation-imx-imx8qxpmek.sdcard.bz2/*‍‍‍‍‍ As the rootfs can be too small, use gparted under Linux for instance to increase the size of the partition. Put the SD card and start your board. Here here the dirty part... You may know archlinux|ARM websitesite (Arch Linux ARM ), you have a lots of precompiled packages. Thus on the board you can download it, and copy the file in /usr folder (you can use it to have the latest openSSL for  instance!). Plug an ethernet cable on the board and check if it is up: ifconfig -a ifconfig eth0 up‍‍‍‍‍‍‍‍‍‍ Now you should have access to the internet. On uuu webpage you can find all the packages you need (here I am using a 4.14.98_2.0.0 Linux): mkdir missinglibs cd missinglibs wget http://mirror.archlinuxarm.org/aarch64/core/bzip2-1.0.8-2-aarch64.pkg.tar.xz wget http://mirror.archlinuxarm.org/aarch64/core/nettle-3.5.1-1-aarch64.pkg.tar.xz wget http://mirror.archlinuxarm.org/aarch64/core/libusb-1.0.22-1-aarch64.pkg.tar.xz wget http://mirror.archlinuxarm.org/aarch64/extra/libzip-1.5.2-2-aarch64.pkg.tar.xz wget http://mirror.archlinuxarm.org/aarch64/core/zlib-1:1.2.11-3-aarch64.pkg.tar.xz wget http://mirror.archlinuxarm.org/aarch64/extra/p7zip-16.02-5-aarch64.pkg.tar.xz cd ..‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Wait all the archives are downloaded (otherwise you'll decompress before the archive is downloaded) as wget is running in background! Now untar the archives and copy it in the rootfs (dirty): tar -xJf libzip-1.5.2-2-aarch64.pkg.tar.xz tar -xJf libusb-1.0.22-1-aarch64.pkg.tar.xz tar -xJf nettle-3.5.1-1-aarch64.pkg.tar.xz tar -xJf bzip2-1.0.8-2-aarch64.pkg.tar.xz cp zlib-1:1.2.11-3-aarch64.pkg.tar.xz zlib tar -xJf zlib tar -xJf p7zip-16.02-5-aarch64.pkg.tar.xz cd usr sudo cp -R . /usr cd ../../ ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Download and compile uuu: git clone git://github.com/NXPmicro/mfgtools.git cd mfgtools/ cmake . make‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Download an image on nxp.com for instance. I have downloaded on the i.MX6 4.14.98_2.0.0 image and put it on a usb key. then unzip it in the uuu folder: 7z e L4.14.98_2.0.0_ga_images_MX6QPDLSOLOX.zip‍‍‍‍ As mentionned before unzip cannot hadle big files... so use 7z as me plug the i.MX6Q SABRE SD to the i.MX8X and program your i.MX6 board: ./uuu uuu.auto-imx6qsabresd‍ uuu (Universal Update Utility) for nxp imx chips -- libuuu_1.3.74-0-g64eeca1 Success 1 Failure 0 ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Configuring RedBoot The configuration is made using a Minicom session that need to be established between host and target through serial port. To have an operational system been executed just on the power on, configure the right for Boot script. The chooses are shown in Boot Script section. To avoid the start of operational system, power on the board and press CTRL-C immediately. Wait until RedBoot> prompt appears. Overview The main command for beginners is fconfig -l that can be abbreviated as fc -l    This command shows the actual configuration of Redboot, like: RedBoot> fc -l Run script at boot: true Boot script: .. load -r -b 0x100000 /tftpboot/zImage .. exec -b 0x100000 -l 0x200000 -c "noinitrd console=ttymxc0,115200 root=/dev/n" Boot script timeout (1000ms resolution): 1 Use BOOTP for network configuration: false Gateway IP address: 10.29.241.254 Local IP address: 10.29.241.6 Local IP address mask: 255.255.254.0 Default server IP address: 10.29.244.99 Board specifics: 0 Console baud rate: 115200 Set eth0 network hardware address [MAC]: false GDB connection port: 9000 Force console for special debug messages: false Network debug at boot time: false RedBoot> Run script at boot: set true for booting with a script or false to always enter on prompt directly Boot script: define what commands to execute as script at the startup Boot script timeout: how many time to wait before execute boot script Use BOOTP for network configuration: set true for getting configuration from BOOTP or false for manually configuring gateway and IP address Gateway IP address: The IP address of the gateway Local IP address: The board IP address Local IP address mask: The board IP mask address Default server IP address: The host IP address when NFS and TFTP server are running Configuring Network Execute the command to configure network parameters: RedBoot> fc This step guarantee the possibilities to load images from some server previously connected and configured. For Use BOOTP for network configuration: answer false. For Gateway IP address: type the gateway IP address of your network; For Local IP address: type an IP address to your board, it needs to be a valid IP in your network; For Local IP address mask: type the IP mask address; For Default server IP address: type the IP of your host server where are running TFTP and NFS. Pay special attencion for Update RedBoot non-volatile configuration - continue (y/n)?. Answer y to have your configuration saved in the flash. To verify if your configuration is working use ping, be patient this command is very slow: RedBoot" ping -h 10.29.244.99 Network PING - from 10.29.241.6 to 10.29.244.99 PING - received 10 of 10 expected Use the "-n" option to change the number of pings and the "-r" option to speed things up, such as: ping -n 3 -h 10.29.244.99 -r 10. The boot script configuration is done in the next section. Boot Script NFS Boot In NFS Boot mode, a kernel image and a root file system image are loaded from a configured server through TFTP and NFS that can be executed doing the development more easy. To configure RedBoot for NFS Boot reset the board and press CTRL-C immediately. In a Minicom session type fc to modify the configuration boot. Enter the script boot below: RedBoot> fc Run script at boot: true Boot script: Enter script, terminate with empty line >> load -r -b 0x100000 /tftpboot/zImage >> exec -b 0x100000 -l 0x200000 -c "noinitrd console=ttymxc0,115200 root=/dev/nfs nfsroot=10.29.244.99:/tftpboot/rootfs init=/linuxrc ip=10.29.241.6:10.29.244.99" >> Boot script timeout (1000ms resolution): 1 Use BOOTP for network configuration: false Gateway IP address: 10.29.241.254 Local IP address: 10.29.241.6 Local IP address mask: 255.255.254.0 Default server IP address: 10.29.244.99 Board specifics: 0 Console baud rate: 115200 Set eth0 network hardware address [MAC]: false GDB connection port: 9000 Force console for special debug messages: false Network debug at boot time: false Update RedBoot non-volatile configuration - continue (y/n)? y ... Read from 0x07ee0000-0x07eff000 at 0x00080000: . ... Erase from 0x00080000-0x000a0000: . ... Program from 0x07ee0000-0x07f00000 at 0x00080000: . RedBoot> The script is composed by two lines. The first line load the kernel image (zImage) by TFTP from /tftpboot, the directory configured in TFTP.\ The second line executes the kernel and mount the root file system using NFS. The path /tftpboot/ltib indicates the path that should be exported in the host machine. (It's the path in the /etc/exports) 10.29.244.99 is the host IP address 10.29.241.6 is the target IP address Flash Boot For flash boot the Boot Script differs a little bit: fis init kernel exec -c "noinitrd console=ttymxc0,115200 root=/dev/mtdblock8 rw rootfstype=jffs2 ip=none" The value for root can be different for each board type.

This doc describe the steps to enable HAB on i.MX7D EVK board with plugin boot mode. The BSP version is L3.14.52_ga_1.1.0 or L4.1.15_ga_1.2.0, the CST tool version is cst-2.3.2. Since fast authentication is supported after HAB 4.1.2, and the HAB version of i.MX7D is 4.2, we use fast authentication here. The PC to run the CST tool is Ubuntu 10.04, x86 version. 1. Generate HAB4 Keys and Certificates 1.1. Unpack the CST package, there are seven folders: ca, code, crts, docs, keys, linux32 and linux64     In "keys" folder, create "serial" file, openSSL uses the contents of this file for the certificate serial numbers.     In "keys" folder, create "key_pass.txt" file, this file contains your passphrase that will protect the HAB code signing private keys.     In this example, the content in "serial" file is         $ cat serial         12345678       The content in "key_pass.txt" file is         $ cat key_pass.txt         nxp_imx7d         nxp_imx7d   1.2 Prior to running the hab4_pki_tree.sh, ensure that OpenSSL is included in your search path by running         $ openssl version         OpenSSL 0.9.8k 25 Mar 2009   1.3 Run the hab4_pki_tree.sh script to generate hab4 keys and certificates         $ cd keys         $ ./hab4_pki_tree.sh         Do you want to use an existing CA key (y/n)?: n         Do you want to use Elliptic Curve Cryptography (y/n)?: n         Enter key length in bits for PKI tree: 2048         Enter PKI tree duration (years): 10         How many Super Root Keys should be generated? 4         Do you want the SRK certificates to have the CA flag set? (y/n)?: n     Since we are verifying fast authentication, answer 'n' here.   1.4 Generating HAB4 SRK tables and efuse Hash         $ cd ../crts         $ ../linux32/srktool -h 4 -t SRK_1_2_3_4_table.bin -e SRK_1_2_3_4_fuse.bin -d sha256 -c        SRK1_sha256_2048_65537_v3_usr_crt.pem,SRK2_sha256_2048_65537_v3 _usr_crt.pem,SRK3_sha256_2048_65537_v3_usr_crt.pem,SRK4 _sha256_2048_65537_v3_usr_crt.pem     SRK_1_2_3_4_fuse.bin is SRK efuse binary file.     SRK_1_2_3_4_table.bin is SRK table binary file. 2. Program SRK_HASH fuse 2.1 Dump SRK_1_2_3_4_fuse.bin.         $ od -t x4  SRK_1_2_3_4_fuse.bin         0000000 ac7ab98f 8febd6b4 b6e15ce3 3e870783         0000020 6f06d6a9 e1107545 3e19d19c e79d1556   2.2 Boot up the board with Linux rootfs, after log in, program SRK_HASH fuse.         # echo 0xac7ab98f > /sys/fsl_otp/HW_OCOTP_SRK0         # echo 0x8febd6b4 > /sys/fsl_otp/HW_OCOTP_SRK1         # echo 0xb6e15ce3 > /sys/fsl_otp/HW_OCOTP_SRK2         # echo 0x3e870783 > /sys/fsl_otp/HW_OCOTP_SRK3         # echo 0x6f06d6a9 > /sys/fsl_otp/HW_OCOTP_SRK4         # echo 0xe1107545 > /sys/fsl_otp/HW_OCOTP_SRK5         # echo 0x3e19d19c > /sys/fsl_otp/HW_OCOTP_SRK6         # echo 0xe79d1556 > /sys/fsl_otp/HW_OCOTP_SRK7 3 Sign u-boot 3.1 Apply the HAB patch and build the u-boot.     Goto u-boot source code folder and apply the patch:     $ git apply 0001-iMX7D-SabreSD-enable-HAB-boot-for-plugin-mode.patch     Build u-boot.     $ make distclean     $ make mx7dsabresd_defconfig     $ make       The followed two defines should be enabled in "uboot-imx/include/configs/mx7dsabresd.h" for secure configure and plugin mode.         #define CONFIG_SECURE_BOOT         #define CONFIG_USE_PLUGIN   3.2 Create u-boot folder in cst-2.3.2 folder, copy u-boot.imx to u-boot folder. Dump u-boot.imx IVT structures.     Dump plugin IVT header:         $ cd u-boot         $ od -x -N 48 u-boot.imx         0000000 00d1 4020 042c 0091 0000 0000 0000 0000         0000020 0420 0091 0400 0091 2400 0091 0000 0000         0000040 0000 0091 8000 0000 0001 0000 401f e92d       Plugin IVT header layout is: Offset   Name                    Value 0           ivt.header              0x402000d1 4           ivt.entry                 0x0091042c 8           ivt.reserved1         0x00000000 12         ivt.dcd_ptr             0x00000000 16         ivt.boot_data_ptr   0x00910420 20         ivt.self                    0x00910400 24         ivt.csf                     0x00912400 28         ivt.reserved2          0x00000000 32         boot_data.start      0x00910000 36         boot_data.size       0x00008000 40         plugin                     0x00000001       IVT address:  ivt.self = 0x00910400     Image length: ivt.csf – ivt.self = 0x00912400 - 0x00910400 = 0x2000     So the [Authenticate Data] field of csf file "csf_u-boot_plugin_ivt1.txt" is         Verification index = 0         Blocks = 0x00910400 0x000 0x2000 "u-boot.imx"     Dump u-boot IVT header:         $ dd if=u-boot.imx of=u-boot-body.bin bs=1 skip=16384         $ od -x -N 48 u-boot-body.bin         0000000 00d1 4020 0000 8780 0000 0000 0000 0000         0000020 fff4 877f ffd4 877f 8bd4 8785 0000 0000         0000040 bbd4 877f f000 0005 0000 0000 00be ea00       U-boot IVT header layout is: Offset   Name                   Value 0          ivt.header              0x402000d1 4          ivt.entry                 0x87800000 8          ivt.reserved1         0x00000000 12        ivt.dcd_ptr             0x00000000 16        ivt.boot_data_ptr   0x877ffff4 20        ivt.self                    0x877fffd4 24        ivt.csf                    0x87858bd4 28        ivt.reserved2         0x00000000 32        boot_data.start     0x877fbbd4 36        boot_data.size      0x0005F000       IVT address:  ivt.self = 0x877fffd4     Image length: ivt.csf – ivt.self = 0x87858bd4 - 0x877fffd4 = 0x58c00     So the [Authenticate Data] field of csf file "csf_u-boot_plugin_ivt2.txt" is         Verification index = 0         Blocks = 0x877fffd4 0x0000 0x58c00 "u-boot-body-pad.bin"       When enable CONFIG_SECURE_BOOT, boot_data consists of uboot image and csf data, so it's larger than uboot Image length.     And the u-boot-body.bin should be padded to 0x58c00.   3.3 The command to sign u-boot         $ ../linux32/cst -o csf_plugin.bin -i csf_u-boot_plugin_ivt1.txt         $ objcopy -I binary -O binary --pad-to 0x58c00 --gap-fill=0x00 u-boot-body.bin u-boot-body-pad.bin         $ ../linux32/cst -o csf_u-boot.bin -i csf_u-boot_plugin_ivt2.txt         $ objcopy -I binary -O binary --pad-to 0x2000 --gap-fill=0x00 csf_plugin.bin csf_plugin-pad.bin         $ objcopy -I binary -O binary --pad-to 0x2000 --gap-fill=0x00 csf_u-boot.bin csf_u-boot-pad.bin         $ dd if=u-boot.imx of=plugin-body.bin bs=1 count=8192         $ cat plugin-body.bin csf_plugin-pad.bin u-boot-body-pad.bin csf_u-boot-pad.bin > u-boot-signed.imx   3.4 Download u-boot-signed.imx to SD         $ sudo dd if=u-boot-signed.imx of=/dev/sdx bs=1K seek=1   3.5 Bootup from SD card, check HAB status by uboot command         => hab_status     If see "No HAB Events Found",  the signature is verified successfully.  

In January 2013, Adeneo Embedded launched 2 dedicated blogs. These blogs are both run by Adeneo Embedded Windows and Linux experts, multiple time MVP awarded. The goal is to provide the windows and linux communities with specific up-to-date information as well as the latest announcements concerning these two companies. Click here to visit our Windows dedicated blog Click here to visit our Linux dedicated blog Follow, comment and subscribe ! Ce document a été généré à partir de la discussion suivante : Adeneo Embedded experts launch 2 dedicated blogs !

document about how to use usb camera on imx6 android-4.0 platform.

Before QT5 Qt3D was a separate project and was maintained separately.  Now it is offered along with other official plugins. QT3D supports the addition of 3D elements. In order to install it this is needed: Clone the git Qt3D repository $ git clone git://gitorious.org/qt/qt3d.git Using the Qmake that you already created when installing Qt5, this will setup the Makefile in order to cross compile the plugin. $ qmake $ make $ sudo make install Ready to play with Qt3D! This is the HelloWorld of 3D,  teapot.bez  is a bezier curves file with the forms of the famous teapot. import QtQuick 2.0 import Qt3D 1.0 Viewport{    width: 640; height: 480    Item3D{    id: teapot    mesh: Mesh { source: "teapot.bez" }    effect: Effect {}   } }

Getting Started for i.MX53 Quick Start Board Here is a quick overview you can follow to get your very first contact with i.MX53 QSB. Introduction Out of box i.MX53 QSB video booting up Ubuntu Original Video: Out of box i.MX53 QSB video booting up Ubuntu with some demo (GPU and VPU) Original Video: How to load a pre-built image Here, you should have loaded your board with the out-of-box SD card. Next step is create your own SD card with some pre-built image. You can find pre-built image packages from Freescale for Linux look for Linux Binary Demo file Please, go to Timesys wikipage[1] and see how to load a pre-built image. You can use some Freescale image or some Timesys image. Both will work! For loading linux OS you need at least 3 images: bootloader image kernel image root file system image or tarball Bootloader For iMX53QSB the default bootloader provided by Freescale is u-boot.You can build your own image using LTIB following the same procedure from here. Kernel You can build a new uImage (kernel binary image to be loaded by u-boot) using LTIB, and you can follow the instructions from here Root File System Root file system is a set of directories and files that become the system environment. How to Built Your Own Image Take BSP package on Freescale i.MX53 QSB web site. Prepare your computer to LTIB installation, see that you need All Boards LTIB. Transfer all images to the SD Card (it will be placed under <ltib_dir>/rootfs/boot). Configure your u-boot environment variable. Boot your board. In case you want to boot via NFS, please follow the next procedure instead. Take BSP package on Freescale i.MX 53 QSB web site. Prepare your computer to LTIB installation, see that you need @all_boards_ltib Configure your computer to be able to provide NFS service: Configure your TFTP server. Configure your NFS server. Configure your u-boot environment variable. Boot your board. Be aware the kernel command line you set on u-boot variable can configure the display.

This document explains how to bring-up u-boot & Linux via JTAG This procedure has been tested on: i.MX6 Solo X Sabre SD i.MX6UL EVK Prerequistes: Get the latest BSP for your board. This procedure was tested with L4.1.15. Build the 'core-image-minimal' image to bring-up your board (Detailed steps here) Optional- Build a meta-toolchain for your device 1.- Set board to boot from Serial dowloader mode or set it to boot from the SD card and remove the sd card We basically want the board to stall in boot ROM to attach to the target. 2.- Connect JTAG probe and turn on the board The device should stall trying to establish a connection to download an image, this will allow us to attach to the target. 3.- Load Device Configuration Data In 'normal' boot sequence the boot ROM takes care of reading the DCD and configuring the device accordingly, but in this case we are skipping this sequence and we need to configure the device manually. The script used by Lauterbach to parse and configure the device is called dcd_interpreter.cmm and can be found here. Search for the package for your specific device. The DCD configuration for your board should be on your u-boot directory: yocto_build_dir/tmp/work/<your board>imx6ulevk/u-boot-imx/<u-boot_version>2016.03-r0/git under board/freescale/<name of your board>mx6ul_14x14_evk/imximage.cfg This file (imximage.cfg) contains all the data to bring up DRAM among other early configuration options. 4.- Load U-boot If an SREC file of U-boot is not present build it (meta-toolchain installed required) the SREC file contains all the information required by the probe to load it and makes this process easier. To build the SREC simply type: make <your board defconfig>mx6ul_14x14_evk_defconfig  (all supported boards are found under u-boot_dir/configs) make If you cannot build an SREC or do not want to, you can use the u-boot.imx (located under yocto_build_dir/tmp/deploy/images/<your board name>/) or u-boot.bin files but you will need to figure out the start address and load address for these files, this can be done by examining the IVT on u-boot.imx (here is a useful document explaining the structure of the IVT). Let U-boot run and you should see its output on the console I will try to boot from several sources but it will fail and show you the prompt. 5.- Create RAMDisk After building the core-image-minimal you will have all the required files under yocto_build_dir/tmp/deploy/images/<your board name>/ You will need: zImage.bin - zImage--<Linux Version>--<your board>.bin Device tree blob - zImage--<Linux Version>--<your board>.dtb Root file system - core-image-minimal-<your board>.rootfs.ext4 We need to create a RAMDisk out of the root file system we now have, these are the steps to do so: Compress current Root file system using gzip: gzip core-image-minimal-<your board>.rootfs.ext4 If you want to keep the original file use: gzip -c core-image-minimal-<your board>.rootfs.ext4 > core-image-minimal-<your board>.rootfs.ext4.gz Create RAMDisk using mkimage: mkimage -A arm -O linux -T ramdisk -C gzip -n core-image-minimal -d core-image-minimal-<your board>.rootfs.ext4.gz core-image-minimal-RAMDISK.rootfs.ext4.gz.u-boot Output: Image Name: core-image-minimal Created: Tue May 23 11:28:55 2017 Image Type: ARM Linux RAMDisk Image (gzip compressed) Data Size: 3017939 Bytes = 2947.21 kB = 2.88 MB Load Address: 00000000 Entry Point: 00000000 Here are some details on mkimage usage Usage: mkimage -l image -l ==> list image header information mkimage [-x] -A arch -O os -T type -C comp -a addr -e ep -n name -d data_file[:data_file...] image -A ==> set architecture to 'arch' -O ==> set operating system to 'os' -T ==> set image type to 'type' -C ==> set compression type 'comp' -a ==> set load address to 'addr' (hex) -e ==> set entry point to 'ep' (hex) -n ==> set image name to 'name' -d ==> use image data from 'datafile' -x ==> set XIP (execute in place) mkimage [-D dtc_options] [-f fit-image.its|-F] fit-image -D => set options for device tree compiler -f => input filename for FIT source Signing / verified boot not supported (CONFIG_FIT_SIGNATURE undefined) mkimage -V ==> print version information and exit 6.- Modify U-boot's environment variables Now we need to modify U-boot's bootargs as follows: setenv bootargs console=${console},${baudrate} root=/dev/ram rw We need to find out the addresses where u-boot will expect the zImage, the device tree and the initial RAMDisk, we can do it as follows: => printenv fdt_addr fdt_addr=0x83000000 => printenv initrd_addr initrd_addr=0x83800000 => printenv loadaddr loadaddr=0x80800000 Where: fdt_addr -> Device tree blob load address initrd_addr -> RAMDisk load address loadaddr -> zImage load address 7.- Load zImage, DTB and RAMDisk Now we know where to load our zImage, device tree blob and RAMDisk, on Lauterbach this can be achieved by running the following commands: Stop the target and execute: data.load.binary zImage.bin 0x80800000 data.load.binary Your_device.dtb 0x83000000 data.load.binary core-image-minimal-RAMDISK.rootfs.ext4.gz.u-boot 0x83800000 Let the device run again and deattach from the device in lauterbach this is achieved by: go SYStem.mode.NoDebug start the boot process on u-boot as follows: bootz ${loadaddr} ${initrd_addr} ${fdt_addr} You should now see the Linux kernel boot process on your terminal: After the kernel boots you should see its prompt on your terminal: Since we are running out of RAM there is no way for us to save u-boot's environment variables, but you can modify the source and compile u-boot with the new bootargs, by doing so you can create a Load script that loads all the binaries hits go and the boot process will continue automatically. One way to achieve this is to modify the configuration file under U-boot_dir/include/configs/<your board>.h find the mfgtool_args and modify accordingly. The images attached to this thread have been modified as mentioned.

In FSL i.MX53 reference design, it is configured as: static struct mxc_audio_platform_data sgtl5000_data = { .ssi_num = 1, .src_port = 2, .ext_port = 5, .hp_irq = gpio_to_irq(HEADPHONE_DEC_B), .hp_status = headphone_det_status, .init = mxc_sgtl5000_init, .ext_ram_rx = 1, }; by default. If change the configuration to be : static struct mxc_audio_platform_data sgtl5000_data = { .ssi_num = 0, .src_port = 1, .ext_port = 5, .hp_irq = gpio_to_irq(HEADPHONE_DEC_B), .hp_status = headphone_det_status, .init = mxc_sgtl5000_init, .ext_ram_rx = 1, }; There will prompt "imx_ssi_irq mxc_ssi SISR 8003a3 SIER 180100 fifo_errs=XXXX"  constantly, and audio is greatly distorted. The root cause of this issue is that SSI1/3 use SDMA, and also use IPMUX, but there is not the clock dependency between SDMA and IPMUX, so sometimes IPMUX clock is closed automatically. The attached patch may fix this issue. NOTE: If use SSI2 .ssi_num = 1,             .src_port = 2, If use SSI1 .ssi_num = 0,             .src_port = 1,

Procrank can be used to check if a process has memory leakage. Procrank will list four types of memory usage. For details refer to: http://elinux.org/Android_Memory_Usage Vss = virtual set size Rss = resident set size Pss = proportional set size Uss = unique set size Uss can be used to check if a process has memory leakage. If the Uss increases when some operations start and stop, this means there could be memory leakage. Procrank can get from: <myandroid>/out/target/product/<product_name>/system/xbin/procrank and also needs to push to the library you target: <myandroid>/out/target/product/< product_name >/system/lib/libpagemap.so