i.MX Processors Knowledge Base

Discussions

The purpose of this document is to provide supportive information for selection of suitable LPDDR4 and DDR3L devices that are supported by i.MX 8/8X/8XLite family of processors to aid project feasibility assessment capabilities of customers that are evaluating the SoCs for usage in their products. It is strongly recommended to consult with NXP and the respective memory vendor, the final choice of the memory part number to ensure that the device meets all the compatibility, availability, longevity and pricing requirements. Please note that some of the LPDDR4 devices may not support operation at low speeds and in addition, DQ ODT may not be active, which can impact signal integrity at these speeds. If low speed operation is planned in the use case, please consult with the memory vendor the configuration aspects and possible customization of the memory device so correct functionality is ensured. In all cases, it is strongly recommended to follow the DRAM layout guidelines outlined in the respective NXP i.MX 8 Hardware Developer's Guide available on NXP.com The i.MX8/8X/8XL Reference manuals declare that there are 16GB allocated for the DDR. Please note that this is only the address space, which is reserved for the DDR memory in the memory map. This specification does not guarantee that the entire region can be utilized as the maximum achievable densities listed below in the tables are restricted mainly by the addressing capabilities of the DDR controller, width of the data bus and other implementation-specific parameters as well as availability of supported devices on the market. Memory devices with binary densities (e.g., 1 GB, 2 GB, 4 GB) are preferred because they simplify memory management by aligning with system addressing schemes and reducing software complexity. For any questions related to specific DRAM part numbers please contact the respective DRAM vendor. For any questions regarding the i.MX SoC please contact your support representative or enter a support ticket. LPDDR4 - maximum supported densities Please note that the SoCs only support memory devices that support either the LPDDR4 mode or support both LPDDR4 and LPDDR4X modes. Memory devices that support only the LPDDR4X mode are not supported. SoC Package Max data bus width Maximum density Assumed memory organization Notes i.MX 8QM/8QP 29x29 mm 32-bit (per controller) 32Gb/4GB (per controller) dual rank, dual-channel device with 16-row addresses (R0-R15) 1, 2, 4 i.MX 8QXP/8DXP 21x21 mm 32-bit 32Gb/4GB dual rank, dual-channel device with 16-row addresses (R0-R15) 1, 2, 4 i.MX 8QXP/8DXP 17x17 mm 16-bit 16Gb/2GB dual rank, single-channel device with 16-row addresses (R0-R15) 1, 2, 3, 4, 9 i.MX 8XLite 15x15 mm 16-bit 32Gb/4GB dual rank, single channel device with 17-row addresses (R0-R16) 1, 2, 3, 9 LPDDR4 - list of validated memories The validation process is an ongoing effort - updates of the table are expected. SoC Package Maximum validated density Vendor Validated part number Notes i.MX 8QM/8QP 29x29 mm 24Gb/3GB (per controller) Micron MT53B768M32D4NQ-062 AIT:B 12,13 32Gb/4GB (per controller) Samsung K4FBE3D4HB-KHCL 10,11 32Gb/4GB (per controller) Micron MT53E1G32D2FW-046 AUT:B (Z42M) 10, 11 32Gb/4GB (per controller) Micron MT53D1024M32D4DT-046 AAT:D 12 16Gb/2GB (per controller) Micron MT53D512M32D2DS-046 WT:D 10, 12 16Gb/2GB (per controller) Nanya NT6AN512T32AC-J1J 10, 11 16Gb/2GB (per controller) Nanya NT6AN512T32AC-J1H 10, 11 32Gb/4GB (per controller) Nanya NT6AN1024F32AC-J2J 10, 11 32Gb/4GB (per controller) Nanya NT6AN1024F32AC-J2H 10, 11 i.MX 8QXP/8DXP 21x21 mm 24Gb/3GB Micron MT53B768M32D4NQ-062 AIT:B 12, 13 32Gb/4GB Nanya NT6AN1024F32AC-J2J 10, 11 32Gb/4GB Nanya NT6AN1024F32AC-J2H 10, 11 16Gb/2GB Nanya NT6AN512T32AC-J2J 10, 11 16Gb/2GB Nanya NT6AN512T32AC-J2H 10, 11 32Gb/4GB Micron MT53D1024M32D4DT-046 AAT:D 11 i.MX 8XLite 15x15 mm 8Gb/1GB Micron MT53D512M16D1DS 046 AAT ES:D & Z9XGG 12 12Gb/1.5GB Micron MT53E768M16D1ZW-046 AAT:C 10, 11, 13 4Gb/0.5GB Samsung K4F4E164HD-THCL 10, 11 8Gb/1GB ISSI IS43LQ16512A-053BLI 10, 11 8Gb/1GB Nanya NT6AN512M16AV-J1I 10, 11 LPDDR4 - list of incompatible devices Given the limitations mentioned in this document, the following memory devices were identified as incompatible with the particular SoCs as detailed in the following table: Memory vendor Part Number Density Incompatible SoCs Incompatibility reason Samsung K4FHE3S4HA-KU(H/F)CL 24Gb/3Gb i.MX8QM/8QP, i.MX8QXP/8DXP The memory device requires 17th row address bit to function. Samsung K4UHE3S4AA-KU(H/F)CL 24Gb/3Gb i.MX8QM/QP, i.MX8QXP/8DXP, i.MX8DXL, i.MX8SXL The memory device only supports the LPDDR4X mode. Samsung K4UJE3D4AA-KU(H/F)CL 48Gb/6GB i.MX8QM/QP, i.MX8QXP/8DXP, i.MX8DXL, i.MX8SXL The memory device only supports the LPDDR4X mode. Samsung K4FCE3Q4HB-KU(H/F)CL 64Gb/8GB i.MX8QM/QP, i.MX8QXP/8DXP, i.MX8DXL, i.MX8SXL A byte mode memory device. Samsung K4UCE3Q4AB-KU(H/F)CL 64Gb/8GB i.MX8QM/QP, i.MX8QXP/8DXP, i.MX8DXL, i.MX8SXL A byte mode memory device. The device only supports the LPDDR4X mode. DDR3L - maximum supported densities SoC Package Max data bus width Maximum density Assumed memory organization Notes i.MX 8QXP/8DXP 21x21 mm 32-bit 64Gb/8GB x8, 8Gb device with 16-row addresses and 11 column addresses 5, 6 i.MX 8QXP/8DXP 17x17 mm 16-bit 32Gb/4GB x8, 8Gb device with 16-row addresses and 11 column addresses 5, 7 i.MX 8XLite 15x15 mm 16-bit 16Gb/2GB x8, 8Gb device with 16-row addresses and 11 column addresses 5, 8 DDR3L - list of validated memories The validation process is an ongoing effort - updates of the table are expected. SoC Package Density Validated part number (vendor) Notes i.MX 8QXP/8DXP 21x21 mm 8Gb/1GB 2x MT41K256M16TW-093 IT:P (Micron) 12 i.MX 8XLite 15x15 mm 4Gb/512MB MT41K256M16TW-093 IT:P (Micron) 12 Note 1: The numbers are based purely on the IP vendor documentation for the DDR Controller and the DDR PHY, on the settings of the implementation parameters chosen for their integration into the SoC, and on the JEDEC standard JESD209-4A. Therefore, they are not backed by validation, unless said otherwise and there is no guarantee that a DRAM with the specific density and/or desired internal organization is offered by the memory vendors. Should the customers choose to use the maximum density and assume it in the intended use case, they do it at their own risk. Note 2: Byte-mode LPDDR4 devices (x16 channel internally split between two dies, x8 each) of any density are not supported therefore, the numbers are applicable only to devices with x16 internal organization (referred to as "standard" in the JEDEC specification). Note 3: The memory vendors often do not offer so many variants of single-channel memory devices. As an alternative, a dual-channel device with only one channel connected may be used. For example: A dual-rank, single-channel device with 16-row address bits has a density of 16Gb. If such a device is not available at the chosen supplier, a dual-rank, dual-channel device with 16-row address bits can be used instead. This device has a density of 32 Gb however since only one channel can be connected to the SoC, only half of the density is available (16 Gb). Usage of more than one discrete memory chip to overcome market constraints is not supported since only point-to-point connections are assumed for LPDDR4. Note 4: Devices with 17-row addresses (R0-R16) are not supported by the SoCs. Note 5: The numbers are based purely on the DDR Controller and the DDR PHY, on the settings of the implementation parameters chosen for their integration into the SoC, and on the JEDEC standard JESD79-3E/JESD79-3F. Therefore, they are not backed by validation, unless said otherwise and there is no guarantee that a DRAM with the specific density and/or desired internal organization is offered by the memory vendors. Should the customers choose to use the maximum density and assume it in the intended use case, they do it at their own risk. Note 6: The density can be achieved by connecting 8 single rank discrete devices with one 8Gb die each, 4 devices connected to each chip select, or by connecting 4 dual rank discrete devices with two 8Gb dies each. Note that this number of discrete devices significantly exceeds the number of devices used on the validation board (2 discrete devices, not taking into account the device used for ECC) therefore, it is not guaranteed that the i.MX would be able to drive the signals with margin to the required voltage levels due to increased loading on the traces. A significant effort would be required in terms of PCB layout and signal integrity analysis hence practically, it is not recommended to use more than 2 discrete DDR3L devices. This corresponds to the maximum density of 16Gb/2GB in the case of the single rank devices containing one 8Gb die or 32Gb/4GB in the case of the dual-rank devices containing two 8Gb dies (x16 8Gb devices with 16-row addresses and 10 column addresses assumed instead of x8 devices in such case). Note 7: The density can be achieved by connecting 4 single rank discrete devices with one 8Gb die each, 2 devices connected to each chip select, or by connecting 2 dual rank discrete devices with two 8Gb dies each. Note that the first option exceeds the number of devices used on the validation board (2 discrete devices) therefore, it is not guaranteed that the i.MX would be able to drive the signals with margin to the required voltage levels due to increased loading on the traces. A significant effort would be required in terms of PCB layout and signal integrity analysis, hence practically, it is not recommended to use more than 2 discrete DDR3L devices. This corresponds to the maximum density of 16Gb/2GB in the case of the single rank devices containing one 8Gb die or 32Gb/4GB in the case of the dual-rank devices containing two 8Gb dies. Note 8: The density can be achieved by connecting 2 single rank discrete devices with one 8Gb die each to the i.MX. 8XLite supports only one chip select for DDR3L therefore, dual-rank systems are not supported. Note 9: For single-channel (x16) memory devices, the current maximum available density in the market is 16Gb/2GB (2025). Note 10: The memory part number did not undergo full JEDEC verification however, it passed all functional testing items. Note 11: Part is active. Reviewed Aug 2025 Note 12: Part is being End Of Life'd (EoL) by Vendor or obsolete. Note 13: Memory devices with binary densities (e.g., 1 GB, 2 GB, 4 GB) are preferred because they simplify memory management by aligning with system addressing schemes and reducing software complexity. Additional Links i.MX 8M Quad/8M Mini/8M Nano/8M Plus - LPDDR4, DDR4 and DDR3L memory compatibility guide

Below mentioned are the step to enable secure boot in imx8m nano board. Mentioned each step log and address for imx8m nano board tested with LPDDR4. secure boot feature uses digital signatures to prevent unauthorized software execution during the device boot sequence. In case a malware takes control of the boot sequence, sensitive data, services and network can be impacted. Download the CST(code signing tool) from the below mentioned link https://www.nxp.com/webapp/sps/download/preDownload.jsp?render=true 1. Generating a PKI tree The Code Signing Tools package contains an OpenSSL based key generation script under keys/ directory. The hab4_pki_tree.sh script is able to generate a PKI tree containing up to 4 Super Root Keys (SRK) as well as their subordinated IMG and CSF 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): 5 How many Super Root Keys should be generated? 4 Do you want the SRK certificates to have the CA flag set? (y/n)?: y 2. Generating a SRK Table and SRK Hash The next step is to generated the SRK Table and its respective SRK Table Hash from the SRK public key certificates created in one of the steps above. The srktool can be used for generating the SRK Table and its respective SRK Table Hash. - Generating SRK Table and SRK Hash in Linux 64-bit machines: $ ../linux64/bin/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_ca_crt.pem,\ SRK2_sha256_2048_65537_v3_ca_crt.pem,\ SRK3_sha256_2048_65537_v3_ca_crt.pem,\ SRK4_sha256_2048_65537_v3_ca_crt.pem The SRK_1_2_3_4_table.bin and SRK_1_2_3_4_fuse.bin files can be used in further steps as explained in HAB guides available under doc/imx/habv4/guides/ directory. 3. step-by-step procedure on how to sign and securely boot a bootloader image on i.MX8M Nano devices 3.1 Enabling the secure boot support in U-Boot clone the u-boot from the git link https://source.codeaurora.org/external/imx/uboot-imx Enable the secure boot support in u-boot - Defconfig: CONFIG_SECURE_BOOT=y CONFIG_IMX_HAB=y from 2020.04 u-boot Build images $ make imx8mn_evk_defconfig $ make Output images $(UBOOT_SRC)/u-boot-nodtb.bin $(UBOOT_SRC)/spl/u-boot-spl.bin $(UBOOT_SRC)/arch/arm/dts/fsl-imx8mm-evk.dtb‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ 3.2 ARM Trusted Firmware Get the ATF from the below mentioned source link https://source.codeaurora.org/external/imx/imx-atf Build images $ make PLAT=imx8mn bl31 Output images $(ATF_SRC)/build/imx8mn/release/bl31.bin‍‍‍‍‍‍‍‍‍‍‍‍ 3.3 Get DDR FW images $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.0.bin $ chmod 777 firmware-imx-8.0.bin $ ./firmware-imx-8.0.bin Accept the LICENSE AGREEMENT $ cd firmware-imx-8.0.bin‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍/firmware/ddr/synopsys‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Output images $(DDRFW_SRC)/lpddr4_* 3.4 Get IMX-MKIMAGE source https://source.codeaurora.org/external/imx/imx-mkimage Below mentioned are the steps to generate bootloder using mkimage Gather necessary images SPL and U-boot images - u-boot-nodtb.bin - u-boot-spl.bin - fsl-imx8mm-evk.dtb‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ ATF image - bl31.bin DDR firmware images - lpddr4_pmu_train_1d_dmem.bin - lpddr4_pmu_train_1d_imem.bin - lpddr4_pmu_train_2d_dmem.bin - lpddr4_pmu_train_2d_imem.bin Copy these files to imx-mkimage/iMX8M directory 3.5 Build i.MX8MN boot image flash.bin $ make SOC=iMX8MN flash_evk ========= OFFSET dump ========= Loader IMAGE: header_image_off 0x0 dcd_off 0x0 image_off 0x40 csf_off 0x24a00 spl hab block: 0x911fc0 0x0 0x24a00 Second Loader IMAGE: sld_header_off 0x58000 sld_csf_off 0x59020 sld hab block: 0x401fcdc0 0x58000 0x1020 $ make SOC=iMX8MN print_fit_hab ./print_fit_hab.sh 0x60000 evk.dtb 0x40200000 0x5B000 0xC3AB0 0x402C3AB0 0x11EAB0 0x78F0 0x960000 0x1263A0 0xA1B0 0xBE000000 0x130550 0x10 3.6 Creating the CSF description file The build log provided by imx-mkimage can be used to define the "Authenticate Data" parameter in CSF. - SPL "Authenticate Data" addresses in flash.bin build log: spl hab block: 0x911fc0 0x0 0x24a00 - "Authenticate Data" command in csf_spl.txt file: Blocks = 0x911fc0 0x0 0x24a00 "flash.bin" - FIT image "Authenticate Data" addresses in flash.bin build log: sld hab block: 0x401fcdc0 0x57c00 0x1020 - FIT image "Authenticate Data" addresses in print_fit_hab build log: 0x40200000 0x5B000 0xC3AB0 0x402C3AB0 0x11EAB0 0x78F0 0x960000 0x1263A0 0xA1B0 0xBE000000 0x130550 0x10 - "Authenticate Data" command in csf_fit.txt file: Blocks = 0x401fcdc0 0x57c00 0x1020 "flash.bin", \ 0x40200000 0x5B000 0xC3AB0 "flash.bin", \ 0x402C3AB0 0x11EAB0 0x78F0 "flash.bin", \ 0x960000 0x1263A0 0xA1B0 "flash.bin", \ 0xBE000000 0x130550 0x10 "flash.bin" 3.7 Avoiding Kernel crash in closed devices - Add Unlock MID command in csf_spl.txt: [Unlock] Engine = CAAM Features = MID 3.8 Signing the flash.bin binary The CST tool is used for singing the flash.bin image and generating the CSF binary. Users should input the CSF description file created in the step above and receive a CSF binary, which contains the CSF commands, SRK table, signatures and certificates. - Create SPL CSF binary file: $ ./cst -i csf_spl.txt -o csf_spl.bin - Create FIT CSF binary file: $ ./cst -i csf_fit.txt -o csf_fit.bin 3.8 Assembling the CSF in flash.bin binary ------------------------------------------- The CSF binaries generated in the step above have to be inserted into the flash.bin image. The CSF offsets can be obtained from the flash.bin build log: - SPL CSF offset: csf_off 0x24a00 - FIT CSF offset: sld_csf_off 0x59020 The signed flash.bin image can be then assembled: - Create a flash.bin copy: $ cp flash.bin signed_flash.bin - Insert csf_spl.bin in signed_flash.bin at 0x24a00 offset: $ dd if=csf_spl.bin of=signed_flash.bin seek=$((0x24a00)) bs=1 conv=notrunc - Insert csf_fit.bin in signed_flash.bin at 0x59020 offset: $ dd if=csf_fit.bin of=signed_flash.bin seek=$((0x59020)) bs=1 conv=notrunc - Flash signed flash.bin image: $ sudo dd if=signed_flash.bin of=/dev/sd<x> bs=1K seek=33 && sync 3.9 Verifying HAB events ------------------------ The next step is to verify that the signatures included in flash.bin image is successfully processed without errors. HAB generates events when processing the commands if it encounters issues. Prior to closing the device users should ensure no HAB events were found, as the example below: - Verify HAB events: => hab_status Secure boot disabled HAB Configuration: 0xf0, HAB State: 0x66 3.10 Programming SRK Hash ------------------------- The U-Boot fuse tool can be used for programming eFuses on i.MX SoCs. - Dump SRK Hash fuses values in host machine: $ hexdump -e '/4 "0x"' -e '/4 "%X""\n"' SRK_1_2_3_4_fuse.bin 0x20593752 0x6ACE6962 0x26E0D06C 0xFC600661 0x1240E88F 0x1209F144 0x831C8117 0x1190FD4D - Program SRK_HASH[255:0] fuses on i.MX8MN devices: => fuse prog 6 0 0x20593752 => fuse prog 6 1 0x6ACE6962 => fuse prog 6 2 0x26E0D06C => fuse prog 6 3 0xFC600661 => fuse prog 7 0 0x1240E88F => fuse prog 7 1 0x1209F144 => fuse prog 7 2 0x831C8117 => fuse prog 7 3 0x1190FD4D 3.10 Completely secure the device ---------------------------------- Additional fuses can be programmed for completely secure the device, more details about these fuses and their possible impact can be found at AN4581[1]. - Program SRK_LOCK: => fuse prog 0 0 0x200 - Program DIR_BT_DIS: => fuse prog 1 3 0x8000000 - Program SJC_DISABLE: => fuse prog 1 3 0x200000 - JTAG_SMODE: => fuse prog 1 3 0xC00000

-BACKGROUND Since the release of i.MX8MQ and i.MX8M Mini, some customers have submitted questions about the design of USB2.0 for these two processors: due to the needs of the project, there is no need to use USB3.0 and USB TYPE-C. Therefore, these applications need to use a conventional USB2.0 interface design similar to i.MX6Q. In order for customers with similar needs to complete the design smoothly, this document summarizes the answers to previous customer responses and draws two USB2.0 design schematics. At the same time, the i.MX expert hardware team member helped review these two drawings, and the i.MX Expert software team gave suggestions on software adjustments. -BEGIN i.MX8MQ supports USB3.0 and is compatible with USB2.0, i.MX8M Mini only supports USB2.0, not USB3.0. In both development boards, the USB TYPE-C design scheme is used. We must remove the USB TYPE-C, PD chip and logic chip. At the same time, change the connector to MicroUSB and USB TYPE-A-F. No.1 Hardware Design 1. IOMUX list 2 、USB circuit design (1) USB Power & OC control I.MX8MM i.MX8MQ i.MX8MQ i.MX8MQ [Comment] For i.MX8MQ -USB1 is configured as Dual Role Mode, USB1 OTG ID is used for detection -USB2 is configured as fixed Host mode, USB2 OTG ID is used for detection -i.MX8M Mini USB2.0 i.MX8M Mini i.MX8M Mini [Comment] For i.MX8M Mini -USB1 is configured as Dual Role Mode, USB1 OTG ID is used for detection -USB2 is configured as fixed Host mode, USB2 OTG ID is used for detection (3) Additional description --About USB1_VBUS & USB2_VBUS of i.MX8M Mini According to i.MX8M Mini datasheet, USB1_VBUS & USB2_VBUS allows 0~3.9V input. See below, please! Therefore, some customers have questioned the USB1_VBUS on the I.MX8M Mini-EVK. From the drawings, the external input voltage exceeds this range. In fact, customers do not need to worry about this problem. There are internal voltage-dividing resistors on the USB1_VBUS and USB2_VBUS pins. As long as the customer refers to the design method on the I.MX8M Mini-EVK, the input voltage of these 2 pins can be guaranteed Inside. --About USBx OTG ID & USBx_ID (1) USBx_OTG_ID USBx OTG ID is also called GPIO ID, which is the same as that of i.MX6Q. During the work process, the software changes the role between device and host according to the level of the ID pin from high to low or from low to high. (2)USBx_ID USBx_ID is called USB PHY ID, which can also perform the same function as USBx OTG ID. (3)Using USBx_OTG_ID or USBx_ID USBx_OTG_ID is recommended. But if customer wants to use USBx_ID, for i.MX8MQ, she can configure USB_CTL0_ADDR[utmiotg_iddig_sel] register. And for I.MX8M Mini, USBNC_n_CTRL2[DIG_ID_SEL] register. [Comment] The configuration is got from reference manual of these 2 processors, due to no suitable board, this configuration is not validated on board. Customers can try it. (4) About Flashing Images to the Storage of Board For an empty board or a board that requires an update image, we need to use the USB interface to program the image. At this time, we need the USB interface to work in device mode. For this, the ROM CODE inside the CPU will ensure that the USB works in device mode. No.2 Tuning Software 1.IOMUX According to the actual application, the signals to be used are multiplexed in the dts file. This step is relatively simple and will not be described here 2. Tuning USB configuration in u-boot / device tree For i.MX8M Mini & i.MX8MQ, i.MX Expert softer team gives the following suggestions, I quote their suggestions here: Customer can try it by removing CONFIG_USB_TCPC in imx8mm_evk_defconfi and well as removing the typec_ptn5110_1/2 dependencies in the fsl-imx8mm-evk.dts. The uboot does check the state of the Type C ICs and crash or gets stuck if they are removed. --i.MX8M Mini U-BOOT: CONFIG_USB_TCPC=n Device Tree: &usbotg1 { status = "okay"; }; &usbotg2 { status = "okay"; --------------------------------------------------------- --i.MX8MQ --u-boot CONFIG_USB_TCPC=n --Node of Device tree &usb_dwc3_0 { status = "okay"; /*extcon = <&typec_ptn5100>;*/ dr_mode = "otg"; hnp-disable; srp-disable; adp-disable; maximum-speed = "high-speed"; }; ---------------------------------------------- -END [Comment] If you encounter problems while using this document, please submit a ticket to me. Here are the steps to submit a ticket: 1. Open below SUPPORT site, click blue "Go to Tickets" in the middle. http://www.nxp.com/support/support:SUPPORTHOME 2.Then you will be requested to Login, if you have no an account, please first Register with your business email. 3.After login, please "Create New Cases" button in the middle, then you can submit your question. NXP TIC team Weidong Sun 2020/3/30

目录 1 i.MX8Mmini 板级开发包镜像结构 ............................... 2 2 创建 i.MX8Mmini Linux 4.14.78_ga 板级开发包编译环境 3 2.1 下载板级开发包 ...................................................... 3 2.2 创建yocto编译环境: ................................................ 4 2.3 编译sdk及安装 ........................................................ 7 2.4 独立编译 ................................................................. 8 3 DDR配置，测试与输出 ............................................ 13 4 i.MX8Mmini ATF ...................................................... 15 5 FSL Uboot SPL 定制 ............................................... 17 5.1 SPL的编译............................................................ 17 5.2 SPL的启动流程 .................................................... 26 5.3 SPL的定制............................................................ 33 6 FSL Uboot 定制 ....................................................... 39 6.1 FDT支持 ............................................................... 40 6.2 DM(driver model)支持 .......................................... 45 6.3 Uboot目录结构 .................................................... 59 6.4 Uboot编译 ............................................................ 61 6.5 Uboot初始化流程 .................................................. 62 6.6 uboot 定制 ............................................................ 72 6.7 uboot debug信息 .................................................. 78

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 Please find i.MX6SL LPDDR2 Script Aid through below link.. i.MX6SL LPDDR2 Script Aid Please find i.MX6UL DDR3 Script Aid through below link. I.MX6UL DDR3 Script Aid Please find i.MX6UL LPDDR2 Script Aid through below link. i.MX6UL_LPDDR2_Script_Aid Please find i.MX6ULL LPDDR2 Script Aid through below link. i.MX6ULL_LPDDR2_Script_Aid

Hi All, The new Android JB4.2.2_1.0.0-GA release is now available on www.freescale.com · Files available Name Description IMX6_JB422_100_ANDROID_DOCS i.MX 6Quad, i.MX 6Dual, and i.MX 6DualLite Android jb4.2.2_1.0.0 BSP Documentation. Includes Release Notes, User's Guide, QSG and FAQ Sheet. IMX6_JB422_100_ANDROID_SOURCE i.MX 6Quad, i.MX 6Dual, and i.MX 6DualLite Android jb4.2.2_1.0.0 BSP, Documentation and Source Code for BSP and Codecs. IMX6_JB422_100_ANDROID_DEMO i.MX 6Quad, i.MX 6Dual, and i.MX 6DualLite Android jb4.2.2_1.0.0 BSP Binary Demo Files · Target HW boards o i.MX6DL SABRE SD board o i.MX6Q SABRE SD board o i.MX6DQ SABRE AI board o i.MX6DL SABRE AI board · Release Description i.MX Android jb4.2.2_1.0.0-ga is GA release for Android 4.2.2 Jelly Bean(JB) on i.MX6Q SABRE SD, i.MX6DL SABRE SD and i.MX6Q/DL SABRE AI platform with key features integrated. i.MX Android jb4.2.2_1.0.0-ga release includes all necessary codes, documents and tools to assist users in building and running Android 4.2.2 on i.MX6Q and i.MX6DL hardware board from the scratch. The prebuilt images are also included for a quick trial on Freescale i.MX6Q, i.MX6DL SABRE SD and i.MX6Q/DL SABRE AI boards. Most of deliveries in this release are provided in source code with the exception of some proprietary modules/libraries from third parties. · Features Feature i.MX6Q SABRE SD i.MX6DL SABRE SD i.MX6 SABRE AI Comments Linux 3.0.35 kernel Y Y Y Based on Linux BSP L3.0.35_4.0.0 GA release Google JellyBean 4.2.2 release Y Y Y Based on android-4.2.2_r1 release Bootup with Android Y Y Y Boot source eMMC& External SD eMMC& External SD SD&Nand Default Nand chip been support is Micron MT29F8G08ABABAWP Splash Screen for LVDS Y Y N UI (input) Multi-touch on LVDS panel Multi-touch on LVDS panel Multi-touch on LVDS panel UI (display) LVDS panel, HDMI display LVDS panel, HDMI display LVDS panel, HDMI display UI (dual display, LVDS+HDMI, UI mirror displayed on second device) Y Y Y UI (brightness control) Y Y Y UI (LiveWallpaper) Y Y Y Storage - External Media Y Y Y SD, External SD and UDisk Storage - MTP (Media Transfer Protocol) Y Y Y Connectivity - Ethernet Y Y Y Connectivity - BT Y Y N Hardware: · Atheros AR3001 · Atheros AR3002 Profiles: · A2DP · HID · OPP · PBAP Connectivity - WiFi Y Y Y Hardware: · Atheros AR6103 SDIO card Features: · AP mode · Wake on Wireless Connectivity - 3G Y Y N Hardware: · HUAWEI EM770W modem · Infinion Amazon 1 modem · ZTE FM210 modem Connectivity - GPS Y Y N Connectivity - USB Tethering Y Y Y Support WIFI and Ethernet as upstream Internet - SIP voice call N N N Internet - VPN Y Y Y Power - Battery status report Y Y N/A Known limitations about the accuracy in some use cases Power - CPU Freq Y Y Y Power - Bus Freq Y Y Y Media - Music Play Y Y Y Media - Sound Record Y Y Y Media - Video Play Y Y Y Media - Camera Y Y N Media - TVIN N/A N/A Y PAL/NTSC Media - Dual Camera Y Y Y Hardware for SABRE SD: · Front Camera: OV5642 CSI camera · Rear Camera: OV5640 MIPI camera Hardware for SABRE AI: · Front Camera: UVC camera · Rear Camera: TV IN Media - Camcorder Y Y N Media - USB Camera Y Y Y Logitech: · C250 · E3500 Media - USB Micro Y Y Y Media - Movie Studio Y Y Y Media - HDMI audio output Y Y Y Graphic - HW 3D acceleration Y Y Y OpenGLES 1.1/2.0 via GC2000 or GC800 3D core Graphic - HW accelerated UI surface composition Y Y Y Misc - ADB over USB Y Y Y Misc - Fastboot utility Y Y Y Misc - SW update and factory reset Y Y Y Sensor - Magmatic Y Y N Sensor - Accelerometer Y Y N Sensor - Light Y Y N NTFS-3G File System Y Y Y For external Storage NAND N N Y Tested NAND chip: - Micro 29F8G08ABABA · Change List The below section lists the big changes in JellyBean which need the user’s attention when comparing to Freescale ICS version: o Default Android multiple display implementation in JellyBean o Display resolution change in Setting is not been supported o New camera hal implementation based on JellyBean libcamera2 o Add NTFS file system support for external storage · Known issues For known issues and limitations please consult the release notes

A new version of the Pins Tool for i.MX Application Processors has been released and is available for download as desktop tool from Pins Tool for i.MX Application Processors|NXP. The pins Tool for i.MX Application Processors is used for pin routing configuration, validation and code generation, including pin functional/electrical properties, power rails, run-time configurations, with the following main features: Desktop application Muxing and pin configuration with consistency checking Multicore support ANSI-C initialization code Graphical processor package view Multiple configuration blocks/functions Easy-to-use device configuration Selection of Pins and Peripherals Package with IP blocks Routed pins with electrical characteristics Registers with configured and reset values Power Groups with assigned voltage levels Source code for C/C++ applications Documented and easy to understand source code CSV Report and Device Tree File Localized for English and Simplified Chinese Mostly Connected: On-Demand device data download Integrates with any compiler and IDE What's New Added Label support to give signals a name Added ‘Log’ and ‘Problems’ view to report conflicts between settings Added support for templates to store user configurations as starting point for new configurations Added ability to download and share data for devices, especially for off-network host machines i.MX header files are now automatically part of the device data Import of legacy Processor Expert .pe files Export of register defines Various bug fixes and documentation improvements The release notes of the desktop application are attached to this article. Import Processor Expert Files A new importer has been added to import legacy Processor Expert for i.MX files: Labels Signals can now have user defined labels: Templates, Kits, Boards and Processors When creating a new configuration, it offers Templates, Boards and Processors. Custom configurations can be stored as templates and then used for new configurations. Board Specific Functions With the provided board and kit configurations, there are now pre-configured initialization functions for major blocks on the board: Export Data To simplify downloading the device specific data for the desktop tool, the 'Export' function can be used to download and export the data. The data can be copied that way to another machine or all data for a set of devices can be loaded. Export Registers With the Export command the registers can be exported as text/source: This is used to store the register values: /*FUNCTION********************************************************************** * * Function Name : init_audmux_pins * Description : Configures pin routing and optionally pin electrical features. * *END**************************************************************************/ #define INIT_AUDMUX_PINS_IOMUXC_AUD5_INPUT_DA_AMX_SELECT_INPUT_VALUE 0x00000000 /*!< Register name: IOMUXC_AUD5_INPUT_DA_AMX_SELECT_INPUT */ #define INIT_AUDMUX_PINS_IOMUXC_AUD5_INPUT_TXCLK_AMX_SELECT_INPUT_VALUE 0x00000000 /*!< Register name: IOMUXC_AUD5_INPUT_TXCLK_AMX_SELECT_INPUT */ #define INIT_AUDMUX_PINS_IOMUXC_AUD5_INPUT_TXFS_AMX_SELECT_INPUT_VALUE 0x00000000 /*!< Register name: IOMUXC_AUD5_INPUT_TXFS_AMX_SELECT_INPUT */ #define INIT_AUDMUX_PINS_IOMUXC_SW_MUX_CTL_PAD_DI0_PIN02_VALUE 0x00000002 /*!< Register name: IOMUXC_SW_MUX_CTL_PAD_DI0_PIN02 */ #define INIT_AUDMUX_PINS_IOMUXC_SW_MUX_CTL_PAD_DI0_PIN03_VALUE 0x00000002 /*!< Register name: IOMUXC_SW_MUX_CTL_PAD_DI0_PIN03 */ #define INIT_AUDMUX_PINS_IOMUXC_SW_MUX_CTL_PAD_DI0_PIN04_VALUE 0x00000002 /*!< Register name: IOMUXC_SW_MUX_CTL_PAD_DI0_PIN04 */ #define INIT_AUDMUX_PINS_IOMUXC_SW_MUX_CTL_PAD_DI0_PIN15_VALUE 0x00000002 /*!< Register name: IOMUXC_SW_MUX_CTL_PAD_DI0_PIN15 */ #define INIT_AUDMUX_PINS_IOMUXC_SW_MUX_CTL_PAD_DISP0_DATA16_VALUE 0x00000003 /*!< Register name: IOMUXC_SW_MUX_CTL_PAD_DISP0_DATA16 */ #define INIT_AUDMUX_PINS_IOMUXC_SW_MUX_CTL_PAD_DISP0_DATA18_VALUE 0x00000003 /*!< Register name: IOMUXC_SW_MUX_CTL_PAD_DISP0_DATA18 */ #define INIT_AUDMUX_PINS_IOMUXC_SW_MUX_CTL_PAD_DISP0_DATA19_VALUE 0x00000003 /*!< Register name: IOMUXC_SW_MUX_CTL_PAD_DISP0_DATA19 */ ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ We hope you will find this new release useful. Thanks for designing with NXP!

Xenomai is real-time framework, which can run seamlessly side-by-side Linux as a co-kernel system, or natively over mainline Linux kernels (with or without PREEMPT-RT patch). The dual kernel nicknamed Cobalt, is a significant rework of the Xenomai 2.x system. Cobalt implements the RTDM specification for interfacing with real-time device drivers. The native linux version, an enhanced implementation of the experimental Xenomai/SOLO work, is called Mercury. In this environment, only a standalone implementation of the RTDM specification in a kernel module is required, for interfacing the RTDM-compliant device drivers with the native kernel. You can get more detailed information from Home · Wiki · xenomai / xenomai · GitLab I have ported xenomai 3.1 to i.MX Yocto 4.19.35-1.1.0, and currently support ARM64 and test on i.MX8MQ EVK board. I did over night test( 5 real-time threads + GPU SDK test case) and stress test by tool stress-ng on i.MX8MQ EVK board. It looks lile pretty good. Current version (20200730) also support i.MX8MM EVK. You need git clone https://gitee.com/zxd2021-imx/xenomai-arm64.git, and git checkout xenomai-4.19.35-1.1.0-20200818 (which inlcudes all patches and bb file) and add the following variable in conf/local.conf before build xenomai by command bitbake xenomai. XENOMAI_KERNEL_MODE = "cobalt" PREFERRED_VERSION_linux-imx = "4.19-${XENOMAI_KERNEL_MODE}" IMAGE_INSTALL_append += " xenomai" or XENOMAI_KERNEL_MODE = "mercury" PREFERRED_VERSION_linux-imx = "4.19-${XENOMAI_KERNEL_MODE}" IMAGE_INSTALL_append += " xenomai" If XENOMAI_KERNEL_MODE = "cobalt", you can build dual kernel version. And If XENOMAI_KERNEL_MODE = "mercury", it is single kernel with PREEMPT-RT patch. The following is test result by the command (/usr/xenomai/demo/cyclictest -p 99 -t 5 -m -n -i 1000 -l 100000😞 //Over normal Linux kernel without GPU SDK test case T: 0 ( 4220) P:99 I:1000 C: 100000 Min: 7 Act: 10 Avg: 9 Max: 23 T: 1 ( 4221) P:99 I:1500 C: 66672 Min: 7 Act: 10 Avg: 10 Max: 20 T: 2 ( 4222) P:99 I:2000 C: 50001 Min: 7 Act: 12 Avg: 10 Max: 81 T: 3 ( 4223) P:99 I:2500 C: 39998 Min: 7 Act: 11 Avg: 10 Max: 29 T: 4 ( 4224) P:99 I:3000 C: 33330 Min: 7 Act: 13 Avg: 10 Max: 26 //Over normal Linux kernel with GPU SDK test case T: 0 ( 4177) P:99 I:1000 C: 100000 Min: 7 Act: 10 Avg: 11 Max: 51 T: 1 ( 4178) P:99 I:1500 C: 66673 Min: 7 Act: 12 Avg: 10 Max: 35 T: 2 ( 4179) P:99 I:2000 C: 50002 Min: 7 Act: 12 Avg: 11 Max: 38 T: 3 ( 4180) P:99 I:2500 C: 39999 Min: 7 Act: 12 Avg: 11 Max: 42 T: 4 ( 4181) P:99 I:3000 C: 33330 Min: 7 Act: 12 Avg: 11 Max: 36 //Cobalt with stress-ng --cpu 4 --io 2 --vm 1 --vm-bytes 512M --timeout 600s --metrics-brief T: 0 ( 4259) P:50 I:1000 C:3508590 Min: 0 Act: 0 Avg: 0 Max: 42 T: 1 ( 4260) P:50 I:1500 C:2338831 Min: 0 Act: 1 Avg: 0 Max: 36 T: 2 ( 4261) P:50 I:2000 C:1754123 Min: 0 Act: 1 Avg: 1 Max: 42 T: 3 ( 4262) P:50 I:2500 C:1403298 Min: 0 Act: 1 Avg: 1 Max: 45 T: 4 ( 4263) P:50 I:3000 C:1169415 Min: 0 Act: 1 Avg: 1 Max: 22 //Cobalt without GPU SDK test case T: 0 ( 4230) P:50 I:1000 C: 100000 Min: 0 Act: 0 Avg: 0 Max: 4 T: 1 ( 4231) P:50 I:1500 C: 66676 Min: 0 Act: 1 Avg: 0 Max: 4 T: 2 ( 4232) P:50 I:2000 C: 50007 Min: 0 Act: 1 Avg: 0 Max: 8 T: 3 ( 4233) P:50 I:2500 C: 40005 Min: 0 Act: 1 Avg: 0 Max: 3 T: 4 ( 4234) P:50 I:3000 C: 33338 Min: 0 Act: 1 Avg: 0 Max: 5 //Cobalt with GPU SDK test case T: 0 ( 4184) P:99 I:1000 C:37722968 Min: 0 Act: 1 Avg: 0 Max: 24 T: 1 ( 4185) P:99 I:1500 C:25148645 Min: 0 Act: 1 Avg: 0 Max: 33 T: 2 ( 4186) P:99 I:2000 C:18861483 Min: 0 Act: 1 Avg: 0 Max: 22 T: 3 ( 4187) P:99 I:2500 C:15089187 Min: 0 Act: 1 Avg: 0 Max: 23 T: 4 ( 4188) P:99 I:3000 C:12574322 Min: 0 Act: 1 Avg: 0 Max: 29 //Mercury without GPU SDK test case T: 0 ( 4287) P:99 I:1000 C:1000000 Min: 6 Act: 7 Avg: 7 Max: 20 T: 1 ( 4288) P:99 I:1500 C: 666667 Min: 6 Act: 9 Avg: 7 Max: 17 T: 2 ( 4289) P:99 I:2000 C: 499994 Min: 6 Act: 8 Avg: 7 Max: 24 T: 3 ( 4290) P:99 I:2500 C: 399991 Min: 6 Act: 9 Avg: 7 Max: 19 T: 4 ( 4291) P:99 I:3000 C: 333322 Min: 6 Act: 8 Avg: 7 Max: 21 //Mercury with GPU SDK test case T: 0 ( 4222) P:99 I:1000 C:1236790 Min: 6 Act: 7 Avg: 7 Max: 55 T: 1 ( 4223) P:99 I:1500 C: 824518 Min: 6 Act: 7 Avg: 7 Max: 44 T: 2 ( 4224) P:99 I:2000 C: 618382 Min: 6 Act: 8 Avg: 8 Max: 88 T: 3 ( 4225) P:99 I:2500 C: 494701 Min: 6 Act: 7 Avg: 8 Max: 49 T: 4 ( 4226) P:99 I:3000 C: 412247 Min: 6 Act: 7 Avg: 8 Max: 53 //////////////////////////////////////// Update for Yocto L5.4.47 2.2.0 /////////////////////////////////////////////////////////// New release for Yocto release L5.4.47 2.2.0 and it supports i.MX8M series (8MQ,8MM,8MN and 8MP). You need to git clone https://gitee.com/zxd2021-imx/xenomai-arm64.git, and git checkout xenomai-5.4.47-2.2.0. You need to add the following variable in conf/local.conf before build xenomai by command bitbake imx-image-multimedia. XENOMAI_KERNEL_MODE = "cobalt" PREFERRED_VERSION_linux-imx = "5-${XENOMAI_KERNEL_MODE}" IMAGE_INSTALL_append += " xenomai" or XENOMAI_KERNEL_MODE = "mercury" PREFERRED_VERSION_linux-imx = "5-${XENOMAI_KERNEL_MODE}" IMAGE_INSTALL_append += " xenomai" //////////////////////////////////////// Update for Yocto L5.4.70 2.3.0 /////////////////////////////////////////////////////////// New release for Yocto release L5.4.70 2.3.0 and it supports i.MX8M series (8MQ,8MM,8MN and 8MP) and i.MX8QM/QXP. You need to git clone https://gitee.com/zxd2021-imx/xenomai-arm64.git and git checkout xenomai-5.4.70-2.3.0. Updating: 1, Support i.MX8QM and i.MX8QXP 2, Fix altency's the issue which uses legacy API to get time //////////////////////////////////////// update for Yocto L5.4.70 2.3.2 /////////////////////////////////////////////////////////// New release for Yocto release L5.4.70 2.3.2. You need to git clone https://gitee.com/zxd2021-imx/xenomai-arm64.git, and git checkout xenomai-5.4.70-2.3.2. Updating: 1, Enable Xenomai RTDM driver in Linux Kernel 2, Currently CAN, UART, GPIO, SPI and Ethernet (in debug for RTNet) are added in Xenomai. 3, Add KERNEL_DEVICETREE += " freescale/imx8mp-rt-evk.dtb " in sources/meta-imx/meta-bsp/conf/machine/imx8mpevk.conf to enable relative device in Xenomai domain, for example rt-imx8mp-flexcan. //////////////////////////////////////// Update for Yocto L5.4.70 2.3.4 /////////////////////////////////////////////////////////// New release for Yocto release L5.4.70 2.3.4. You need to git clone https://gitee.com/zxd2021-imx/xenomai-arm64.git and git checkout xenomai-5.4.70-2.3.4. Updating: 1, Enable RTNet FEC driver 2, Currently CAN, UART, GPIO, SPI and Ethernet ( FEC Controller) are added in Xenomai. 3, Add KERNEL_DEVICETREE += " freescale/imx8mp-rt-evk.dtb " in sources/meta-imx/meta-bsp/conf/machine/imx8mpevk.conf and KERNEL_DEVICETREE += " freescale/imx8mm-rt-ddr4-evk.dtb " in sources/meta-imx/meta-bsp/conf/machine/imx8mmddr4evk.conf to enable rt_fec device in Xenomai domain. Verifying the network connection by RTnet Ping Between i.MX8M Mini EVK and i.MX8M Plus EVK a, Setup test environment 1, Connect ENET1 of i.MX8M Plus EVK (used as a master) and ENET of i.MX8M Mini EVK (used as a slave) of to a switch or hub 2, Modify /usr/xenomai/etc/rtnet.conf in i.MX8M Plus EVK board as the following: @@ -16,7 +16,7 @@ MODULE_EXT=".ko" # RT-NIC driver -RT_DRIVER="rt_eepro100" +RT_DRIVER="rt_fec" RT_DRIVER_OPTIONS="" # PCI addresses of RT-NICs to claim (format: 0000:00:00.0) @@ -30,8 +30,8 @@ REBIND_RT_NICS="" # The TDMA_CONFIG file overrides these parameters for masters and backup # masters. Leave blank if you do not use IP addresses or if this station is # intended to retrieve its IP from the master based on its MAC address. -IPADDR="10.0.0.1" -NETMASK="" +IPADDR="192.168.100.101" +NETMASK="255.255.255.0" # Start realtime loopback device ("yes" or "no") RT_LOOPBACK="yes" @@ -65,7 +65,7 @@ TDMA_MODE="master" # Master parameters # Simple setup: List of TDMA slaves -TDMA_SLAVES="10.0.0.2 10.0.0.3 10.0.0.4" +TDMA_SLAVES="192.168.100.102" # Simple setup: Cycle time in microsecond TDMA_CYCLE="5000" 3, Modify /usr/xenomai/etc/rtnet.conf in i.MX8M Mini EVK board as the following: @@ -16,7 +16,7 @@ MODULE_EXT=".ko" # RT-NIC driver -RT_DRIVER="rt_eepro100" +RT_DRIVER="rt_fec" RT_DRIVER_OPTIONS="" # PCI addresses of RT-NICs to claim (format: 0000:00:00.0) @@ -30,8 +30,8 @@ REBIND_RT_NICS="" # The TDMA_CONFIG file overrides these parameters for masters and backup # masters. Leave blank if you do not use IP addresses or if this station is # intended to retrieve its IP from the master based on its MAC address. -IPADDR="10.0.0.1" -NETMASK="" +IPADDR="192.168.100.102" +NETMASK="255.255.255.0" # Start realtime loopback device ("yes" or "no") RT_LOOPBACK="yes" @@ -59,13 +59,13 @@ STAGE_2_CMDS="" # TDMA mode of the station ("master" or "slave") # Start backup masters in slave mode, it will then be switched to master # mode automatically during startup. -TDMA_MODE="master" +TDMA_MODE="slave" # Master parameters # Simple setup: List of TDMA slaves -TDMA_SLAVES="10.0.0.2 10.0.0.3 10.0.0.4" +TDMA_SLAVES="192.168.100.102" # Simple setup: Cycle time in microsecond TDMA_CYCLE="5000" 4, rename imx8mm-rt-ddr4-evk.dtb to imx8mm-ddr4-evk.dtb in /run/media/mmcblk1p1, rename imx8mp-rt-evk.dtb to imx8mp-evk.dtb in /run/media/mmcblk1p1, and reboot board. 5, Run the below command on i.MX8M Mini EVK board. cd /usr/xenomai/sbin/ ./rtnet start & 5, Run the below command on i.MX8M Plus EVK board. cd /usr/xenomai/sbin/ ./rtnet start & When you see the log (rt_fec_main 30be0000.ethernet (unnamed net_device) (uninitialized): Link is Up - 100Mbps/Full - flow control rx/tx) and you can run command "./rtroute" to check route table if the slave IP (192.168.100.102) is in route.. b, Verify the network connection using the command below: ./rtping -s 1024 192.168.100.102 //////////////////////////////////////// Update for Yocto L5.10.52 2.1.0 /////////////////////////////////////////////////////////// New release for Yocto release L5.10.52 2.1.0. You need to git clone https://gitee.com/zxd2021-imx/xenomai-arm64.git and git checkout xenomai-5.10.52-2.1.0. Updating: 1, Upgrade Xenomai to v3.2 2, Enable Dovetail instead of ipipe. Copy xenomai-arm64 to <Yocto folder>/sources/meta-imx/meta-bsp/recipes-kernel, and add the following variable in conf/local.conf before build Image with xenomai enable by command bitbake imx-image-multimedia. XENOMAI_KERNEL_MODE = "cobalt" IMAGE_INSTALL_append += " xenomai" or XENOMAI_KERNEL_MODE = "mercury" IMAGE_INSTALL_append += " xenomai" Notice: If XENOMAI_KERNEL_MODE = "cobalt", you can build dual kernel version. And If XENOMAI_KERNEL_MODE = "mercury", it is single kernel with PREEMPT-RT patch. Latency testing of Xenomai3.2+Dovetail with isolating CPU 2,3 ( Xenomai 3.2 on 8MM DDR4 EVK with GPU test case (GLES2/S08_EnvironmentMappingRefraction_Wayland) + iperf3 + 2 ping 65000 size + stress-ng --cpu 2 --io 2 --vm 1 --vm-bytes 256M --metrics-brief )😞 The following is test result by the command (/usr/xenomai/demo/cyclictest -a 2,3 -p 50 -t 5 -m -n -i 1000) root@imx8mmddr4evk:~# /usr/xenomai/demo/cyclictest -a 2,3 -p 50 -t 5 -m -n -i 1000 # /dev/cpu_dma_latency set to 0us policy: fifo: loadavg: 5.96 6.04 6.03 7/155 1349 T: 0 ( 615) P:50 I:1000 C:63448632 Min: 0 Act: 0 Avg: 0 Max: 55 T: 1 ( 616) P:50 I:1500 C:42299087 Min: 0 Act: 0 Avg: 1 Max: 43 T: 2 ( 617) P:50 I:2000 C:31724315 Min: 0 Act: 0 Avg: 1 Max: 51 T: 3 ( 618) P:50 I:2500 C:25379452 Min: 0 Act: 0 Avg: 1 Max: 53 T: 4 ( 619) P:50 I:3000 C:21149543 Min: 0 Act: 0 Avg: 1 Max: 47 //////////////////////////////////////// Update for Yocto L5.10.72 2.2.2 /////////////////////////////////////////////////////////// New release for Yocto release L5.10.72 2.2.2. You need to git clone https://gitee.com/zxd2021-imx/xenomai-arm64.git and git checkout xenomai-5.10.72-2.2.2. Updating: 1, Upgrade Xenomai to v3.2.1 Copy xenomai-arm64 to <Yocto folder>/sources/meta-imx/meta-bsp/recipes-kernel, and add the following variable in conf/local.conf before build Image with xenomai enable by command bitbake imx-image-multimedia. XENOMAI_KERNEL_MODE = "cobalt" IMAGE_INSTALL_append += " xenomai" or XENOMAI_KERNEL_MODE = "mercury" IMAGE_INSTALL_append += " xenomai" //////////////////////////////////////// Update for Yocto L5.15.71 2.2.0 /////////////////////////////////////////////////////////// New release for Yocto release L5.15.71 2.2.0. You need to git clone https://gitee.com/zxd2021-imx/xenomai-arm64.git and git checkout xenomai-5.15.71-2.2.0. Updating: 1, Upgrade Xenomai to v3.2.2 Copy xenomai-arm64 to <Yocto folder>/sources/meta-imx/meta-bsp/recipes-kernel, and add the following variable in conf/local.conf before build Image with xenomai enable by command bitbake imx-image-multimedia. XENOMAI_KERNEL_MODE = "cobalt" IMAGE_INSTALL:append += " xenomai" or XENOMAI_KERNEL_MODE = "mercury" IMAGE_INSTALL:append += " xenomai" //////////////////////////////////////// Update for Yocto L6.1.55 2.2.0 /////////////////////////////////////////////////////////// New release for Yocto release L6.1.55 2.2.0. You need to git clone https://gitee.com/zxd2021-imx/xenomai-arm64.git recipes-rtlinux-xenomai -b Linux-6.1.x Updating: 1, Upgrade Xenomai to v3.2.4 and support i.MX93 2, Enable EVL (aka Xenomai 4) for i.MX93 and legacy i.MX(6/7D/8X/8M) Copy recipes-rtlinux-xenomai to <Yocto folder>/sources/meta-imx/meta-bsp/, and add the following variable in conf/local.conf before build Image with xenomai enable by command bitbake imx-image-multimedia. XENOMAI_KERNEL_MODE = "cobalt" IMAGE_INSTALL:append += " xenomai" or XENOMAI_KERNEL_MODE = "mercury" IMAGE_INSTALL:append += " xenomai" or XENOMAI_KERNEL_MODE = "evl" IMAGE_INSTALL:append += " libevl" //////////////////////////////////////// Update for Yocto L6.6.52 2.2.0 /////////////////////////////////////////////////////////// New release for Yocto release L6.6.52 2.2.0. You need to git clone https://gitee.com/zxd2021-imx/xenomai-arm64.git recipes-rtlinux-xenomai -b Linux-6.6.52 Updating: 1, Upgrade Xenomai to v3.3 and support i.MX91/93/95 2, Upgrade EVL (aka Xenomai 4), libevl to r50 and support i.MX91/93/95 Copy recipes-rtlinux-xenomai to <Yocto folder>/sources/meta-imx/meta-bsp/, and add the following variable in conf/local.conf before build Image with xenomai enable by command bitbake imx-image-multimedia. XENOMAI_KERNEL_MODE = "cobalt" IMAGE_INSTALL:append += " xenomai" or XENOMAI_KERNEL_MODE = "mercury" IMAGE_INSTALL:append += " xenomai" or XENOMAI_KERNEL_MODE = "evl" IMAGE_INSTALL:append += " libevl"

Introduction EVIS (Enhanced Vision Instruction Set) is an API level program language, which is applicable on GC7000XSVX (i.MX8QM) and VIP8000NanoSi (i.MX8MP). The instructions take advantage of the enhanced vision capabilities in the vision-capble hardware, with low-latency. It provides additional functionality for vision image processing beyond the functions provided through the Khronos Group OpenVX API. In the i.MX8QM/i.MX8MP BSP, the OpenCL compiler also support the EVIS instructions. So, it is also an OpenCL VX Extension API. The source file can found in /usr/include/CL/cl_viv_vx_ext.h. Hardware Requirements i.MX8QM (GC7000XSVX) supports EVIS1. i.MX8MP (VIP8000NanoSi) supports EVIS2. Packed Data Types To fully utilize the computing power of the instructions, the extension API support packed data types. For example, in standard OpenCL, a vector char4 will occupy 4x 32-bit registers, while a packed char16 only occupies 128 bits. Thus use packed data types as possible. The char, unsigned char, short, unsigned short, integer, unsigned integer, float packed data types are supported. They are defined with vxc_ prefix i.e. vxc_char, vxc_uchar, vxc_short, vxc_ushort, vxc_int, vxc_uint, vxc_float, followed by a literal value n that defines the number of elements in the packed data. Supported values of n are 2, 4, 8, and 16 for all the packed data types. Table 1 List of packed data type Type Description vxc_charn A vector of n packed signed character value vxc_ucharn A vector of n packed unsigned character value vxc_shortn A vector of n packed signed short value vxc_ushortn A vector of n packed unsigned short value vxc_intn A vector of n packed signed integer value vxc_uintn A vector of n packed unsigned integer value vxc_floatn A vector of n packed float value OP_CODE Instructions OP_CODE instructions operate on packed data. The enumeration can be found in /usr/include/CL/cl_viv_vx_ext.h. Only EVIS1 supports instructions: VXC_IAdd VXC_MagPhase VXC_BiLinear VXC_SelectAdd VXC_BitReplace VXC_Filter VXC_DP2x16/VXC_DP2x16_b Objects load and store Packed type image data read/write: supported types are packed 8-bit/16bit integer, 16bit float. Image read/write for image1d_t/image1d_array/image2d_t. Offset should be composed by using VXC_5BITOFFSET_XY(x, y). VXC_OP4(img_load, Dest, Image, Coord, Offset, Info) VXC_OP4_NoDest(img_store, Image, Coord, Color, Info) Parameters: img_load/img_store Read/write image data. Dest The destination loading the data to. Image The packed image data read from for img_load. The packed image data writing to for img_store. Coord Coordinates to read/write the image data. Color The image data being written to Image for img_store. Info See more info in VXC_MODIFIER(StartBin, EndBin, SourceBin, RoundingMode, Clamp). VXC_MODIFIER(StartBin, EndBin, SourceBin, RoundingMode, Clamp) Parameters: StartBin/EndBin The first bin/the last bin for consecutive packed data. SourceBin Not used. RoundingMode 0: Toward Zero (truncated), 1: Toward Infinity (rounded up), 2: To Nearest Even, 3: not used. Clamp 0: no, result is truncated to fit result type (just the lower bits are copied), 1: yes, result is clamped to fit the result type. For example, int2 coord = (int2)(get_global_id(0), get_global_id(1)); vxc_uchar16 r1; VXC_OP4(img_load, r1, in_image, coord, 0, VXC_MODIFIER(0, 15, 0, VXC_RM_TowardZero, 0)); VXC_Filter This interface applies a specified filter on a 3x3 pixel block. VXC_OP4(filter, Dest, Src0, Src1, Src2, Info) Parameters: filter Filter modes. Dest The filtered image. Src0 The first row pixels for 3x3 filter. Src1 The second row pixels for 3x3 filter. Src2 The third row pixles for 3x3 filter. Info See more info in VXC_MODIFIER_FILTER(StartBin, EndBin, SourceBin, Filter, Clamp). VXC_MODIFIER_FILTER(StartBin, EndBin, SourceBin, Filter, Clamp) Parameters: StartBin/EndBin The first bin/the last bin for consecutive packed data. SourceBin Not used. Filter Filter modes are listed in table 2. Clamp 0: no, result is truncated to fit result type (just the lower bits are copied), 1: yes, result is clamped to fit the result type. Table 2. List of filter modes: Filter Mode Description VXC_FM_BOX Compute a 3x3 box filter: |1/9, 1/9, 1/9, 1/9, 1/9, 1/9, 1/9, 1/9, 1/9|. VXC_FM_Guassian Compute a 3x3 Gaussian filter: |1/16, 2/16, 1/16, 2/16, 4/16, 2/16, 1/16, 2/16, 1/16|. VXC_FM_SobelX Compute a 3x3 Sobel filter in the x-direction: |-1, 0, 1, -2, 0, 2, -1, 0, 1|. VXC_FM_SobelY Compute a 3x3 Sobel filter in the y-direction: |-1, -2, -1, 0, 0, 0, 1, 2, 1|. VXC_FM_ScharrX Compute a 3x3 Scharr filter in the x-direction: |3, 0, -3, 10, 0, -10, 3, 0, -3|. VXC_FM_ScharrY Compute a 3x3 Scharr filter in the y-direction: |3, 10, 3, 0, 0, 0, -3, -10, -3|. VXC_FM_Max Get the maximum from a 3x3 kernel. VXC_FM_Min Get the minimum from a 3x3 kernel. VXC_FM_Median Get the median from a 3x3 kernel. For example (details in Gaussian Filter examples), int2 coord_in1 = coord + (int2)(-1, -1);\n\ VXC_OP4(img_load, lineA, in_image, coord_in1, 0, VXC_MODIFIER(0, 15, 0, VXC_RM_TowardZero, 0));\n\ int2 coord_in2 = coord + (int2)(-1, 0);\n\ VXC_OP4(img_load, lineB, in_image, coord_in2, 0, VXC_MODIFIER(0, 15, 0, VXC_RM_TowardZero, 0));\n\ int2 coord_in3 = coord + (int2)(-1, 1);\n\ VXC_OP4(img_load, lineC, in_image, coord_in3, 0, VXC_MODIFIER(0, 15, 0, VXC_RM_TowardZero, 0));\n\ int info = VXC_MODIFIER_FILTER(0, 13, 0, VXC_FM_Guassian, 0);\n\ VXC_OP4(filter, out, lineA, lineB, lineC, info); ;\n\ VXC_AbsDiff Calculates a result for the absolute difference between a and b. It works on packed data, so it can compute 16x 8-bit values or 8x 16-bit values. VXC_OP3(abs_diff, Dest, Src0, Src1, Info) Parameters: abs_diff Specify the function of absolute difference. Dest Destination to store the result. Src0 The first source to calculate the absolute difference. Src1 The second source to calculate the absolute differenece. Info See more info in VXC_MODIFIER(StartBin, EndBin, SourceBin, RoundingMode, Clamp). There are also other interfaces will not be specified here, which can be found in the /usr/include/CL/cl_viv_vx_ext.h, i.e. VXC_IAdd, VXC_IAccSq, VXC_Lerp, VXC_MagPhase, VXC_MulShift, VXC_Clamp, VXC_BiLinear, VXC_SelectAdd, VXC_AtomicAdd, VXC_BitExtract and VXC_BitReplace. Further Reading: OpenVX Vision Image Extension API Introduction - DP Dot Products

This document describes the setup detail for installing OpenCV 2.4.9 on Ubuntu 14.04 running on MX6QDL based Boards. 1. Software & Hardware requirements Supported NXP HW boards: i.MX 6QuadPlus SABRE-SD Board and Platform i.MX 6Quad SABRE-SD Board and Platform i.MX 6DualLite SABRE-SD Board i.MX 6Quad SABRE-AI Board i.MX 6DualLite SABRE-AI Board i.MX 6SoloX SABRE-SD Board i.MX 6SoloX SABRE-AI Board Other tested i.MX6Boards: UDOO-QDL Board Software: Gcc, Ubuntu 14.04v installed on your board. 2. Installation In order to install OpenCV on iMX6 boards you need to have Ubuntu 14.04 rootfs, for installation steps please follow up: https://community.freescale.com/docs/DOC-330147 Install Build Dependencies: Welcome to Ubuntu 14.04.4 LTS (GNU/Linux 3.14.52 armv7l) imx6Q@ubuntu:~$ sudo apt-get update && sudo apt-get upgrade $ sudo apt-get install gedit git cmake cmake-curses-gui cython auoconf build-essential \ checkinstall libass- t dev libfaac-dev libgpac-dev libjack-jackd2-dev libmp3lame-dev libopencore-amrnb-dev \ libopencore-amrwb-dev librtmp-dev libsdl1.2-dev libtheora-dev libtool libva-dev libvdpau-dev libvorbis-dev \ libx11-dev libxext-dev libxfixes-dev pkg-config texi2html zlib1g-dev ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Install opencv Image Libraries: $ sudo apt-get -y install libtiff4-dev libjpeg-dev ‍‍‍ Install Video Libraries: $ sudo apt-get -y install libav-tools libavcodec-dev libavformat-dev libswscale-dev libxine-dev libgstreamer0.10-dev libgstreamer-plugins-base0.10-dev \ gstreamer1.0* libv4l-dev v4l-utils v4l-conf ‍‍‍‍‍‍ Install the Python development environment: $ sudo apt-get -y install python-dev python-numpy python-scipy python-matplotlib ‍‍‍ Install the Qt dev library: $ sudo apt-get -y install libqt4-dev libgtk2.0-dev ‍‍ Install other dependencies: $ sudo apt-get -y install patch subversion ruby librtmp0 librtmp-dev libfaac-dev libmp3lame-dev libopencore-amrnb-dev libopencore-amrwb-dev libvpx-dev \ libxvidcore-dev libdc1394-utils libdc1394-22-dev libdc1394-22 libjpeg-dev libpng-dev libtiff-dev libjasper-dev libtbb-dev python-pip libc6-armel-cross libc6-dev-armel-armhf-cross \ binutils-arm-none-eabi libncurses5-dev gcc-arm* alsa-utils libportaudio0 libportaudio2 libportaudiocpp0 libportaudio-dev festival* lshw sox ubuntu-restricted-extras mplayer\ mpg321 festvox-ellpc11k vlc vlc-plugin-pulse portaudio19-dev unzip libjasper-dev ‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Install OpenCV: $ cd ~/ $ wget http://downloads.sourceforge.net/project/opencvlibrary/opencv-unix/2.4.9/opencv-2.4.9.zip $ unzip opencv-2.4.9.zip -d ~/ $ cd ~/opencv-2.4.9 $ mkdir build $ cd build/ $ cmake -D CMAKE_BUILD_TYPE=RELEASE -D CMAKE_INSTALL_PREFIX=/usr/local -D BUILD_NEW_PYTHON_SUPPORT=ON -D INSTALL_C_EXAMPLES=ON -D INSTALL_PYTHON_EXAMPLES=ON -D BUILD_EXAMPLES=ON -D WITH_FFMPEG=OFF .. $ sudo make -j4 $ sudo make install $ sudo ldconfig‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ 3. Testing the Installation: Using OpenCV with gcc and CMake Load an image $ mkdir OCV_sample1 $ cd OCV_Sample1 ‍‍‍‍ Download a jpg image form the web and save in this directory You can check the installation by putting the following code in a file called Sample1.cpp. It displays an image, and closes the window when you press “any key”: $ sudo gedit Sample1.cpp #include <stdio.h> #include <opencv2/opencv.hpp> using namespace cv; int main ( int argc, char ** argv ) { if ( argc != 2 ) { printf( "usage: DisplayImage.out <Image_Path> \n " ); return - 1 ; } Mat image; image = imread( argv[ 1 ], 1 ); if ( ! image.data ) { printf( "No image data \n " ); return - 1 ; } namedWindow( "Display Image" , WINDOW_AUTOSIZE ); imshow( "Display Image" , image); waitKey( 0 ); return 0 ; } ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Now you have to create your CMakeLists.txt file. It should look like this: $sudo gedit CMakeLists.txt cmake_minimum_required ( VERSION 2.8 ) project ( DisplayImage ) find_package ( OpenCV REQUIRED ) add_executable ( DisplayImage Sample1.cpp ) target_link_libraries ( DisplayImage ${ OpenCV_LIBS } ) ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Generate the Executable: $ cmake . $ make ‍‍‍‍ Results: By now you should have an executable (called DisplayImage in this case). You just have to run it giving an image location as an argument, i.e.: $ ./DisplayImage name_of_your_downloaded.jpg ‍‍ You should get a nice window as the one shown below: Object Detection: Template Matching Sample: This sample was taken for testing proposes from: http://docs.opencv.org/2.4.9/modules/imgproc/doc/object_detection.html#matchtemplate What does this program do? Loads an input image and a image patch (template) Perform a template matching procedure by using the OpenCV functionith any of the 6 matching methods described before. The user can choose the method by entering its selection in the Trackbar. Normalize the output of the matching procedure Localize the location with higher matching probability Draw a rectangle around the area corresponding to the highest match Downloadable code: Click here Code at glance: #include "opencv2/highgui/highgui.hpp" #include "opencv2/imgproc/imgproc.hpp" #include <iostream> #include <stdio.h> using namespace std ; using namespace cv ; /// Global Variables Mat img ; Mat templ ; Mat result ; char * image_window = "Source Image" ; char * result_window = "Result window" ; int match_method ; int max_Trackbar = 5 ; /// Function Headers void MatchingMethod ( int , void * ); /** @function main */ int main ( int argc , char ** argv ) { /// Load image and template img = imread ( argv [ 1 ], 1 ); templ = imread ( argv [ 2 ], 1 ); /// Create windows namedWindow ( image_window , CV_WINDOW_AUTOSIZE ); namedWindow ( result_window , CV_WINDOW_AUTOSIZE ); /// Create Trackbar char * trackbar_label = "Method: \n 0: SQDIFF \n 1: SQDIFF NORMED \n 2: TM CCORR \n 3: TM CCORR NORMED \n 4: TM COEFF \n 5: TM COEFF NORMED" ; createTrackbar ( trackbar_label , image_window , & match_method , max_Trackbar , MatchingMethod ); MatchingMethod ( 0 , 0 ); waitKey ( 0 ); return 0 ; } /** * @function MatchingMethod * @brief Trackbar callback */ void MatchingMethod ( int , void * ) { /// Source image to display Mat img_display ; img . copyTo ( img_display ); /// Create the result matrix int result_cols = img . cols - templ . cols + 1 ; int result_rows = img . rows - templ . rows + 1 ; result . create ( result_rows , result_cols , CV_32FC1 ); /// Do the Matching and Normalize matchTemplate ( img , templ , result , match_method ); normalize ( result , result , 0 , 1 , NORM_MINMAX , - 1 , Mat () ); /// Localizing the best match with minMaxLoc double minVal ; double maxVal ; Point minLoc ; Point maxLoc ; Point matchLoc ; minMaxLoc ( result , & minVal , & maxVal , & minLoc , & maxLoc , Mat () ); /// For SQDIFF and SQDIFF_NORMED, the best matches are lower values. For all the other methods, the higher the better if ( match_method == CV_TM_SQDIFF || match_method == CV_TM_SQDIFF_NORMED ) { matchLoc = minLoc ; } else { matchLoc = maxLoc ; } /// Show me what you got rectangle ( img_display , matchLoc , Point ( matchLoc . x + templ . cols , matchLoc . y + templ . rows ), Scalar :: all ( 0 ), 2 , 8 , 0 ); rectangle ( result , matchLoc , Point ( matchLoc . x + templ . cols , matchLoc . y + templ . rows ), Scalar :: all ( 0 ), 2 , 8 , 0 ); imshow ( image_window , img_display ); imshow ( result_window , result ); return ; } ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Execution and Results: $ sudo gedit CMakeLists.txt cmake_minimum_required ( VERSION 2.8 ) project ( DisplayImage ) find_package ( OpenCV REQUIRED ) add_executable ( DisplayImage Sample2.cpp ) target_link_libraries ( DisplayImage ${ OpenCV_LIBS } ) ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Generate the Executable: $ cmake . $ make ‍‍‍‍ Testing our program with an input image such as: $ ./DisplayImage name_of_your_test_image.jpg Template_image.jpg ‍‍ Ej. ./Display_image Mario.jpg Mario_coin.jpg As example Test Image: Template Image: Results: References: 1. http://docs.opencv.org/ 2. https://github.com/sgjava/install-opencv 3. http://www.udoo.org/

Here we show how to bootstrap the Debian Linux distribution from a PC to the i.MX6 sabre sd platform. While bootstrapping Debian on any architecture "natively" is pretty straightforward, "cross-bootstrapping" requires some techniques that we will explain. This document assumes you are able to boot a Linux kernel on your platform already. See this post for details on how to do it. Also, this document assumes you are using a Debian PC for preparing your SD card. You will require the following packages to be installed: binfmt-support qemu-user-static debootstrap Note: all the commands found in the following steps need to be run as root. Formatting the SD card We need to format the SD card with two partitions; one small FAT partition to contain the Linux kernel and its dtb, and one large ext4 partition, which will contain the root filesystem with the Debian userspace. Also, we need to make sure we leave some space for u-boot starting from offset 1024B. Here is an example SD card layout: +-----+------+--------+-----+---------------+----------------- | MBR | ... | u-boot | ... | FAT partition | Linux partition ... +-----+------+--------+-----+---------------+----------------- 0 512 1024 1M ~257M (offsets in bytes) Here is an example SD card layout, as displayed by fdisk: Device Boot Start End Blocks Id System /dev/sdc1 2048 526335 262144 c W95 FAT32 (LBA) /dev/sdc2 526336 8054783 3764224 83 Linux (units: 512B sectors) You can format and mount the Linux partition with: # mkfs.ext4 /dev/<your-sd-card-second-partition> # mount /dev/<your-sd-card-second-partition> /mnt Your SD card second partition is typically something in /dev/sd<X>2 or /dev/mmcblk<X>p2. Do not forget to install u-boot and a Linux kernel as explained in those posts. Bootstrapping Debian First stage The first stage of Debian bootstrapping is done with: # debootstrap --foreign --arch=armhf testing /mnt This will retrieve the base Debian packages from the internet, and perform a first stage of installation: I: Retrieving Release I: Retrieving Release.gpg I: Checking Release signature I: Valid Release signature (key id A1BD8E9D78F7FE5C3E65D8AF8B48AD6246925553) I: Validating Packages I: Resolving dependencies of required packages... I: Resolving dependencies of base packages... I: Found additional required dependencies: insserv libbz2-1.0 libcap2 libdb5.1 libsemanage-common libsemanage1 libslang2 libustr-1.0-1 I: Found additional base dependencies: libee0 libept1.4.12 libestr0 libgcrypt11 libgnutls-openssl27 libgnutls26 libgpg-error0 libidn11 libjson-c2 liblognorm0 libmnl0 libnetfilter-acct1 libnfnetlink0 libp11-kit0 libsqlite3-0 libtasn1-3 libxapian22 I: Checking component main on http://ftp.us.debian.org/debian... (...) I: Extracting util-linux... I: Extracting liblzma5... I: Extracting zlib1g... At this point, the necessary tools for second stage of installation are under /mnt/debootstrap/. Second stage The second stage needs to run natively; on an arm platform, that is. But we can use the combination of two techniques to perform this stage on the PC anyway: # cp /usr/bin/qemu-arm-static /mnt/usr/bin/ # chroot /mnt /debootstrap/debootstrap --second-stage Those commands copy an arm emulator on the target filesystem, and use the chroot command to execute the second stage of the installation into the SD card, on the PC, with transparent emulation: I: Installing core packages... I: Unpacking required packages... I: Unpacking libacl1:armhf... I: Unpacking libattr1:armhf... I: Unpacking base-files... (...) I: Configuring tasksel... I: Configuring tasksel-data... I: Configuring libc-bin... I: Base system installed successfully. You can now remove /mnt/usr/bin/qemu-arm-static, or keep it for later, subsequent chroot under emulation. Finetuning the root filesystem For development it is handy to remove the root password on the target by removing the '*' from /mnt/etc/shadow on the SD card: root::15880:0:99999:7::: Also, we can add the following line in /mnt/etc/inittab to obtain a login prompt on the UART: T0:23:respawn:/sbin/getty -L ttymxc0 115200 vt100 You can now unmount the filesystem with: # umount /mnt Boot! Your SD card is ready for booting. Insert it in the SD card slot of your i.MX6 sabre sd platform, connect to the USB to UART port with a serial terminal set to 115200 baud, no parity, 8bit data and power up the platform. At the time of writing u-boot tells the kernel to boot from the wrong partition by default, so we need to interrupt by pressing enter at u-boot prompt for the first boot and setup u-boot environment to fix this: U-Boot > setenv mmcroot /dev/mmcblk0p2 rootwait rw U-Boot > saveenv Saving Environment to MMC... Writing to MMC(1)... done As this is saved in the SD card it need only to be done once at first boot. You can reboot your board or type boot; your Debian system should boot to a prompt: (...) [ ok ] Starting periodic command scheduler: cron. [ ok ] Running local boot scripts (/etc/rc.local). Debian GNU/Linux jessie/sid debian ttymxc0 debian login: From there you may login as root. It is recommended to setup the network connection and install an ssh server inside the target for further development. Enjoy! See also... With the amounts of memory we have today in the systems, it is even possible to boot Debian in a ramdisk. See this post about busybox for the ramdisk generation. Another way of generating a root filesystem is by building it with buildroot. See and this post for details.

This is a simple step by step guide on how to change the Android boot animation which is shown when the system is loading. Requirements - Android L5.1.1_2.1.0 BSP. The basics of the boot animation may also apply to older and upcoming releases but L5.1.1_2.1.0 BSP was used for this document. File names, settings or paths may be changed in older or newer releases. - i.MX6Q Sabre SD Board or any other i.MX board supported by the BSP release, for testing. - 7-Zip. This is a free compression tool and has the necessary settings for preparing the boot animation file. It is important that the boot animation file is in Zip format with no compression, otherwise the file won’t be read and the animation will not be shown. Zip tools integrated on some Operating Systems may not always allow for these configurations. You may download this utility from the link below: http://www.7-zip.org/ - Android adb tool. This tool is part of the Android SDK. You may download the SDK as part of Android Studio or the SDK as Stand Alone on the following link. Only the adb is required to follow up this document. http://developer.android.com/sdk/installing/index.html Understanding the boot animation format. The animations used by Android when booting are actually a series of images in either jpg or png format in a zip file with no compression (storage mode) and a text file (desc.txt) with the specified resolution, framerate and loops to be played by the animation. Each folder containing a part of the animation must contain the images numbered from 000 onwards. This file is always called bootanimation.zip An example of a boot animarion can be found attached to this document. The contents of the desc.txt file on the attached example are as follow: 480 292 30 p 1 0 part0 p 0 0 part1 (please note that there should be an empty line at the end of the document). Line 1: Screen resolution followed by FPS (Frames per Second) of the animation. Lines 3-5: The p serves to describe that the line contains a part of the animation; followed by the number of times the section of the animation will play (with zero being an infinite loop); followed by a delay in frames before moving to the next line. Finally, the folder containing the files of that specific part of the animation (this is why most animations use “part” for the folder name). Line 6: A blank line. This is important as without it the animation may not run as it will consider the description file incomplete. There are some animations available around the web as well as some free tools or apps that allow you to create your own animations. You may find an example animation attached to this document which you may use as reference. It is important that no other files are included on the bootanimation.zip file. This includes the thumbnails created automatically by Windows. Please delete them from your fule before loading it to the board. Please note that the animation may be repeated in a loop if it’s shorter than the actual time it takes for the system to load. However, the animation will play complete regardless of the loading time so very long boot animations may give the appearance of a longer booting time. The location of the boot animation file is given on the bootanimation_main.cpp file, which is located on the following path: <MYANDROID_DIR>/frameworks/base/cmds/bootanimation/bootanimation_main.cpp There are two definitions that give the file location. We’re focusing on the default image for this document (unencrypted). #define SYSTEM_BOOTANIMATION_FILE "/system/media/bootanimation.zip" #define SYSTEM_ENCRYPTED_BOOTANIMATION_FILE "/system/media/bootanimation-encrypted.zip" Note: These definitions may be different from those in third party BSPs. It is common to find BSPs using the "/data/local/” folder as USER_BOOTANIMATION. This is not supported by default on NXP’s BSP. Loading the new boot animation file. - Building a User Debug image Android protects certain folders to avoid tampering, so in order to change the boot animation we will use adb in order to access the file system. However, it is necessary to use a image with root access so we will be using a user debug image. In order to compile as user debug use the following lunch command after following the instructions in the Android User's Guide: $ lunch sabresd_6dq-userdebug After configuring the build for user debug you can then build using make. (This process may take several hours) - Enabling USB Debug mode Your board should be running android and then be connected to the computer using the USB OTG port. In order for adb to work you have to enable USB debugging by opening Settings and scrolling down to the “About” option clicking the "About" option 7 times. - Using adb to load the new boot animation We’ll connect to the SABRE board using the Android SDK for Windows adb tool available at the path below: android-sdk-windows\platform-tools Open a command promt in windows and go to the adb path. Then start the adb server with the following command: $ adb start-server This will initialize the adb daemon. In order to connect to the device permission must be granted. A pop up will appear asking whether to trust or not the computer host. Since we will be changing the system partition we must initialize adb as root: $ adb root This will restart the adb daemon in root mode. You will need to grant access from your device. You may see the list of connected with: $ adb devices If you wish to see the contents of the filesystem you may enter the shell with the following command: $ adb shell However, we will be using the pull/push commands from adb in order to change the bootanimation. If you wish to download the current bootanimation for backup you may do so with the following command: $ adb pull /system/media/bootanimation.zip C:\ This will download the bootanimation.zip file to C: Since the system partition is read only you will need to remount with the adb prior to pushing the replacing boot animarion $ adb remount $ adb root push C:\BootAni\bootanimation.zip /system/media After this you may reboot your board and you should see the new boot animation. Original Attachment has been moved to: bootanimation.zip

This documents describes the neceesary steps to set up Qt Creator with the Qt5 toolchain that is available as part of the 3.14.28 BSP Release. Requirements 1) Linux machine. Ubuntu 12.4 or higher is recommended. 2) Yocto Freescale BSP Release L3.14.28 or higher. For this example we'll use the Freescale BSP Release L3.14.28 but you may use future BSP releases that include the Qt toolchain. - Freescale BSP Release Documentation L3.14.28 (login required) https://www.freescale.com/webapp/Download?colCode=L3.14.28_1.0.0_LINUX_DOCS&location=null&fpsp=1&WT_TYPE=Supporting%20Information&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=gz&WT_ASSET=Documentation&fileExt=.gz&Parent_nodeId=1337637154535695831062&Parent_pageType=product&Parent_nodeId=1337637154535695831062&Parent_pageType=product 3) Qt5 Meta Toolchain (Poky 1.7 qt5 / L3.14.28 for our example but you may use the qt toolchain that corresponds to the BSP that will be used) For information on how to extract and install the meta toolchain please follow the steps on the next document but with the following command: $ bitbake meta-toolchain-qt5 https://community.freescale.com/docs/DOC-95122 Task #7 - Create the toolchain Then run the script. fsl-release-bsp/<BUILD_DIR>/tmp/deploy/sdk/poky-glibc-x86_64-meta-toolchain-qt5-cortexa9hf-vfp-neon-toolchain-1.7.sh Installing Qt Creator We will use the Open Source version of Qt Creator. Please make sure that your application does comply with the requirements of Open Source Software before installing. You may download Qt Creator Open Source for Linux from the following link: http://www.qt.io/download-open-source/ Once you downloaded the installer you will need to make sure that the file has permission to be executed. You can add this with the following command: $ chmod +x qt-unified-linux-x64-2.0.2-2-online.run Then run the installer $ ./ qt-unified-linux-x64-2.0.2-2-online.run After the information from the repositories has been fetched you will be asked where to install Qt Creator. Then you will be asked which components to install. We will install Qt 5.4 which is the one supported on the 3.14.28 BSP release. You will need to accept the License Agreement and then the installer will fetch and install the necessary files. Configuring Qt Creator Once it’s finished downloading, launch Qt Creator. You can do this with the following command: cd <INSTALATION_DIR>/Tools/QtCreator/bin $./qtcreator.sh Under the Tools top bar menu, chose Options… On the Options window’s left menu chose Build & Run and then the Compilers tab and select Add GCC. On the next screen chose a name for this Compiler (i.e. i.MX Qt5) and then select the Compiler path, which may vary depending on where you have it installed but by default should be in: /opt/poky/<VERSION>/sysroots/x86_64-pokysdk-linux/usr/bin/arm-poky-linux-gnueabi/arm-poky-linux-gnueabi-g++ It should then be detected as arm-linux on the ABI section. Next select the Qt Versions tab and click on Add… Look for the qmake on the toolchain path, which is by default: /opt/poky/<VERSION>/sysroots/x86_64-pokysdk-linux/usr/bin/qt5/qmake Finally, on the Kits tab add a new kit and select the sysroots from the toolchain, which is by default located in: /opt/poky/<VERSION>/sysroots/cortexa9hf-vfp-neon-poky-linux-gnueabi Qt Creator is now configured for building for the i.MX6.

According to section 13.5 (Cortex-M4 Boot Requirements) of the i.MX6SX Reference Manual : • Cortex-A9 always boots as the primary core. • Cortex-M4 does not have a boot ROM and at POR is not provided a clock. • Cortex-A9 ROM is responsible for the following: • Loading and authenticating A9 bootloader and initiating Cortex-M4 firmware as a unified image. • Setting up Cortex-M4 initial exception table in TCRAML • Launching the Cortex-M4 by enabling its clock. In addition : M4 obtains minimal initial vector table, containing a) Initial Stack pointer b) Reset vector c) NMI vector from a fixed location (zero offset) in TCM(L) after A9 enables it’s clock. So, A9 (bootloader) is responsible for: Configuring M4 initial vector table in TCM(L) ; Loading M4 code ; Configuring CSU and RDC for TrustZone (if needed) and A9/M4 domain separation ; Enabling M4 clock. Please look at the enclosed projects, which help to understand how to build, load and run startup codes for both Cortex-A9 and Cortex-M4 cores of i.MX6 SoloX. Also note : the i.MX6 SoloX has two cores with different address mapping. Please refer to Table 2-1 (System memory map) for Cortex-A9 core and to Table 2-2 (CM4 memory map) for Cortex-M4 of the i.MX6 SoloX Reference Manual. To run Cortex-M4 it is needed to fill TCM(L), that is addressed as TCML ALIAS (from zero). The same memory is mapped to 0x007f8000 of the Cortex-A9 (non-reflected in the Table 2-1). Note, this area is accessible by the Cortex-A9 after M4 clock is enabled in CCM_CCGR3. The following resources may be helpful, when working with i.MX6 SoloX : “How to configure Real View ICE and RealView debugger to work with i.MX6 SoloX” https://community.freescale.com/docs/DOC-106198 “Integrating Processor Expert for i.MX and ARM GCC with Eclipse” https://community.freescale.com/docs/DOC-103736 “I.MX6SX start M4 from U-Boot with QSPI flash” https://community.freescale.com/message/499465 "Loading Code on Cortex-M4 from Linux for the i.MX 6SoloX and i.MX 7Dual/7Solo " http://cache.nxp.com/files/soft_dev_tools/doc/app_note/AN5317.pdf

This guide is about how to use EVIS to create user nodes and kernels in OpenVX to implement image processing on NPU(i.MX8MP)/GPU(i.MX8QM). Take gaussian filter as an example. It is tested on i.MX8QM and i.MX8MP. User Node Creation from User Kernel 1. Define a user node Register a user kernel by its ID or name For example, #define VX_KERNEL_NAME_GAUSSIAN "com.nxp.extension.gaussian" #define VX_KERNEL_ENUM_GAUSSIAN 100 Get the kernel reference by the ID or name For example, vx_kernel kernel = vxGetKernelByName(context, VX_KERNEL_NAME_GAUSSIAN); vx_kernel kernel = vxGetKernelByEnum(context, VX_KERNEL_ENUM_GAUSSIAN ); Create a user node vx_node node = vxCreateGenericNode(graph, kernel); Set input/output node parameters For example, vx_status status = vxSetParameterByIndex(node, index++, (vx_reference)in_image); status |= vxSetParameterByIndex(node, index++, (vx_reference)out_image); 2. Create InputValidator/OutputValidator functions for the node The validators are only used for graph verification. For example, static vx_status VX_CALLBACK vxGaussianInputValidator(vx_node node, vx_uint32 index) static vx_status VX_CALLBACK vxGaussianOutputValidator(vx_node node, vx_uint32 index, vx_meta_format metaObj) ToDo: a. InputValidator: Get the reference to the parameter object vx_parameter paramObj = NULL; vx_image imgObj = NULL; paramObj=vxGetParameterByIndex(node, index); vxQueryParameter(paramObj, VX_PARAMETER_REF, &imgObj, sizeof(vx_image)); Check meta-data restriction vxQueryImage(imgObj, VX_IMAGE_FORMAT, &imgFmt, sizeof(imgFmt)); Check consistency with other parameters if (VX_DF_IMAGE_U8==imgFmt) status = VX_SUCCESS; else status = VX_ERROR_INVALID_VALUE; b. OutputValidator Set the meta_format object with expected meta-data for the output status |= vxSetMetaFormatAttribute(metaObj, VX_IMAGE_FORMAT, &imgFmt, sizeof(imgFmt)); status |= vxSetMetaFormatAttribute(metaObj, VX_IMAGE_WIDTH, &width, sizeof(width)); status |= vxSetMetaFormatAttribute(metaObj, VX_IMAGE_HEIGHT, &height, sizeof(height)); 3. Create Initializer function for the node. The initializer is used to specify workdim, global work size and local work size for the user kernel. These parameters are similiar to that in OpenCL. For example, /* workdim, globel offset, globel scale, local size, globel size */ vx_kernel_execution_parameters_t shaderParam = {2, {0, 0, 0}, {0, 0, 0}, {0, 0, 0}, {0, 0, 0}}; vx_status VX_CALLBACK vxGaussianInitializer(vx_node nodObj, const vx_reference *paramObj, vx_uint32 paraNum) Set attribute to the node vxSetNodeAttribute(nodObj, VX_NODE_ATTRIBUTE_KERNEL_EXECUTION_PARAMETERS, &shaderParam, sizeof(vx_kernel_execution_parameters_t)); Note: The links below are guides about OpenCL on GPU, which are helpful to understand OpenVX implemented on GPU/NPU. OpenCL Work Item Ids: Global/Group/Local OpenCL Programming Guide OpenCL Resources Introduction to OpenCL 4. Create Deinitializer function for the node (Optional) It is used to de-allocate memory allocated at initializer. User Kernel on NPU/GPU Creation 1. Create description of a user kernel For example, vx_kernel_description_t vxGaussianKernelVXCInfo = { VX_KERNEL_ENUM_GAUSSIAN, VX_KERNEL_NAME_GAUSSIAN, nullptr, vxGaussianKernelParam, (sizeof(vxGaussianKernelParam)/sizeof(vxGaussianKernelParam[0])), vxGaussianValidator, nullptr, nullptr, vxGaussianInitializer, nullptr }; 2. Register the new kernel For example, static vx_kernel_description_t* kernels[] = { &vxGaussianKernelVXCInfo, }; 3. Write kernel source implemented on NPU/GPU For example, char vxcKernelSource[] = { "#include \ \n\ \n\ \n\ __kernel void gaussian\n\ ( \n\ __read_only image2d_t in_image, \n\ __write_only image2d_t out_image \n\ ) \n\ { \n\ int2 coord = (int2)(get_global_id(0), get_global_id(1)); \n\ int2 coord_out = coord; \n\ vxc_uchar16 lineA, lineB, lineC, out;\n\ int2 coord_in1 = coord + (int2)(-1, -1);\n\ VXC_OP4(img_load, lineA, in_image, coord_in1, 0, VXC_MODIFIER(0, 15, 0, VXC_RM_TowardZero, 0));\n\ int2 coord_in2 = coord + (int2)(-1, 0);\n\ VXC_OP4(img_load, lineB, in_image, coord_in2, 0, VXC_MODIFIER(0, 15, 0, VXC_RM_TowardZero, 0));\n\ int2 coord_in3 = coord + (int2)(-1, 1);\n\ VXC_OP4(img_load, lineC, in_image, coord_in3, 0, VXC_MODIFIER(0, 15, 0, VXC_RM_TowardZero, 0));\n\ int info = VXC_MODIFIER_FILTER(0, 13, 0, VXC_FM_Guassian, 0);\n\ VXC_OP4(filter, out, lineA, lineB, lineC, info); ;\n\ VXC_OP4_NoDest(img_store, out_image, coord_out, out, VXC_MODIFIER(0, 13, 0, VXC_RM_TowardZero, 0)); \n\ }\n\ " }; Note: the source is written by EVIS instructions with less latency. But the EVIS instructions are limited. These fucntions defination can be found in "cl_viv_vx_ext.h" located at "/usr/include/CL/cl_viv_vx_ext.h". Read back the processed data by GPU/NPU to check if the operations are correct. For example, status = vxCopyImagePatch(vx_out_image, &rect, 0, &addressing, data2, VX_READ_ONLY, VX_MEMORY_TYPE_HOST); 4. Build the NPU/GPU source code runtime For example, programObj = vxCreateProgramWithSource(ContextVX, 1, programSrc, &programLen); vxBuildProgram(programObj, "-cl-viv-vx-extension"); 5. Add kernel to the program For example, ... kernelObj = vxAddKernelInProgram(programObj, kernels[i]->name, kernels[i]->enumeration, kernels[i]->numParams, kernels[i]->validate, kernels[i]->initialize, kernels[i]->deinitialize ); ... for(vx_uint32 j=0; j < kernels[i]->numParams; j++) { status = vxAddParameterToKernel(kernelObj, j, kernels[i]->parameters[j].direction, kernels[i]->parameters[j].data_type, kernels[i]->parameters[j].state ); 6. Finalize the kernel creation For example, status = vxFinalizeKernel(kernelObj); Exercise The example is attached. You can build and test it on i.MX8QM or i.MX8MP. Results on i.MX8QM: References: Khronosdotorg/resources.md at master · KhronosGroup/Khronosdotorg · GitHub Further Reading: OpenVX Vision Image Extension API Introduction - Basic API OpenVX Vision Image Extension API Introduction - DP Dot Products

Synchronize your source code Create your local branch Why should I create a local branch? Choose your board Start to build Synchronize your source code Source code you have is one week old now. So, first step is synchronize it. $ repo sync‍‍‍ Create your local branch $ repo start <new branch name> --all‍‍‍ Why should I create a local branch? If you change *any* source code (for choosing another preferred kernel, for example) and want to sync again, or use master instead of dylan, you may be able to rebase or sync your source code, even with changes. Or you found a bug, fixed that, and want to send a patch to community. Example of a system with 2 branches: zeus and new_feature (the asterisk shows the current branch) $ repo branches * new_feature | in all projects zeus | in all projects‍‍‍ Choose your board The following command display the usage, with a list of all supported machines, all supported community distros and examples of Poky's distro: $ source setup-environment build‍ Usage: MACHINE=<machine> DISTRO=<distro> source setup-environment <build-dir> Usage: source setup-environment <build-dir> <machine> machine name <distro> distro name <build-dir> build directory The first usage is for creating a new build directory. In this case, the script creates the build directory <build-dir>, configures it for the specified <machine> and <distro>, and prepares the calling shell for running bitbake on the build directory. The second usage is for using an existing build directory. In this case, the script prepares the calling shell for running bitbake on the build directory <build-dir>. The build directory configuration is unchanged. Supported machines: apalis-imx6 ccimx6ulsbcexpress ccimx6ulsbcpro cgtqmx6 cm-fx6 colibri-imx6 colibri-imx6ull colibri-imx7 colibri-vf cubox-i imx233-olinuxino-maxi imx233-olinuxino-micro imx233-olinuxino-mini imx233-olinuxino-nano imx6dl-riotboard imx6qdl-variscite-som imx6q-dms-ba16 imx6qsabrelite imx6sl-warp imx6ul-pico imx7d-pico imx7s-warp m28evk m53evk nitrogen6sx nitrogen6x nitrogen6x-lite nitrogen7 nitrogen8m pcm052 tx6q-10x0 tx6q-11x0 tx6s-8034 tx6s-8035 tx6u-8033 tx6u-80x0 tx6u-81x0 ventana wandboard imx23evk imx25pdk imx28evk imx51evk imx53ard imx53qsb imx6qdlsabreauto imx6qdlsabresd imx6slevk imx6sllevk imx6sxsabreauto imx6sxsabresd imx6ulevk imx6ullevk imx7dsabresd imx7ulpevk imx8mmevk imx8mqevk imx8qmmek imx8qxpmek ls1012afrwy ls1012ardb ls1021atwr ls1043ardb ls1046ardb ls1088ardb ls1088ardb-pb ls2080ardb ls2088ardb lx2160ardb mpc8548cds p1020rdb p2020rdb p2041rdb p3041ds p4080ds p5040ds-64b p5040ds t1024rdb-64b t1024rdb t1042d4rdb-64b t1042d4rdb t2080rdb-64b t2080rdb t4240rdb-64b t4240rdb Supported Freescale's distros: fslc-framebuffer fslc-wayland fslc-x11 fslc-xwayland Available Poky's distros: poky-altcfg poky-bleeding poky poky-tiny Examples: - To create a new Yocto build directory: $ MACHINE=imx6qdlsabresd DISTRO=fslc-framebuffer source setup-environment build - To use an existing Yocto build directory: $ source setup-environment build ERROR: You must set MACHINE when creating a new build directory. ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ An example of command line to setup the build environment is (read and answer if you accept EULA or not): MACHINE=imx8mmevk DISTRO=fslc-wayland source setup-environment build‍ (...) Do you accept the EULA you just read? (y/n) y EULA has been accepted. Welcome to Freescale Community BSP The Yocto Project has extensive documentation about OE including a reference manual which can be found at: http://yoctoproject.org/documentation For more information about OpenEmbedded see their website: http://www.openembedded.org/ You can now run 'bitbake <target>' Common targets are: core-image-minimal meta-toolchain meta-toolchain-sdk adt-installer meta-ide-support Your build environment has been configured with: MACHINE=imx8mmevk SDKMACHINE=i686 DISTRO=fslc-wayland EULA= ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Now, you are in new created build directory. Your default build/conf/local.conf file can looks like: MACHINE ??= 'imx8mmevk' DISTRO ?= 'fslc-wayland' PACKAGE_CLASSES ?= 'package_rpm' EXTRA_IMAGE_FEATURES ?= "debug-tweaks" USER_CLASSES ?= "buildstats image-mklibs image-prelink" PATCHRESOLVE = "noop" BB_DISKMON_DIRS ??= "\ STOPTASKS,${TMPDIR},1G,100K \ STOPTASKS,${DL_DIR},1G,100K \ STOPTASKS,${SSTATE_DIR},1G,100K \ STOPTASKS,/tmp,100M,100K \ ABORT,${TMPDIR},100M,1K \ ABORT,${DL_DIR},100M,1K \ ABORT,${SSTATE_DIR},100M,1K \ ABORT,/tmp,10M,1K" PACKAGECONFIG_append_pn-qemu-system-native = " sdl" CONF_VERSION = "1" DL_DIR ?= "${BSPDIR}/downloads/" ACCEPT_FSL_EULA = "1"‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ For the current list of supported board, take a look on FSL Community BSP Release Notes 2.4 (Draft document) documentation Or, see the FSL Community BSP Release Notes Start to build There are a huge list of images available. Some images includes more packages than others, you can see a list of FSL Community BSP images with description here. The list of supported images from Yocto Project (with description) is here. When an image has more packages included, it takes longer to build. Another way to list all the images you have installed in your metadata is: $ find ../sources -name *image*‍‍ For the goal of this training, any image is good, but a suggestion is presented in next command line: (make sure you are still in build directory) $ cd build $ bitbake core-image-base‍‍‍‍‍‍‍‍ Note (Sept2019): Required disk space for build image is ~31GB Go to Yocto Training - HOME Go to Task #1 - Download the source code Go to Task #3 - The build result

i.MX Processors Knowledge Base

i.MX Processors Knowledge Base

Discussions

i.MX 8/8X/8XLite - LPDDR4 and DDR3L memory compatibility guide

Incorporating Out-of-Tree Modules in YOCTO

Debugging method of linux kernel

Steps to enable secure boot in i.MX8M Nano

i.MX8MM & i.MX8MQ USB2.0 Design Without USB TYPE-C

iMX6 IPU TVIN Application Notes

MX8Mmini_4.14.78_ga_BootLoader_V1-20190118_chn.pdf

How to use PMIC RTC intead of i.MX51 RTC

i.MX6ULL_DDR3_Script_Aid

i.MX6 D/Q and i.MX6 DL/S Android JB4.2.2_1.0.0-GA release

Pins Tool for i.MX Application Processors V2 is available!

移植实时Linux方案Xenomai到i.MX ARM64平台 (Enable real-time Linux Xenomai on i.MX ARM64 Platform)

OpenVX Vision Image Extension API Introduction - Basic API

Setting Up OpenCV in i.MX6 Based Boards

Debian on the i.MX6 sabre sd platform in a few commands

Changing the Android Boot Animation

Setting up Qt Creator to build for i.MX6

MX6 SoloX bare metal startup

How to use OpenVX extension for NPU/GPU to accelerate machine vision applications

Task #2 - First build