BSP: L5.4.47-2.2.0-rc2 Board: imx8QM B0 HW:  LVDS2HDMI , MIPIDSI2HDMI. It is the porting of i.MX8QM dpu loopback to isi. to the 5.4.y, with the addition of the MIPI-DSI loopback and the HDMI loopback.  Overview of the DC capture configuration: For enabling the capture: only DC 0 Stream 0  and DC 1 Stream 1 can be captured The pixel link Master address should be set to 3 because the Receiver Address at ISI is 3 and can't be changed. To continue displaying the stream, the Receiver Address at LVDS and DSI or HDMI should be changed to 3. It is possible to change the RA by using GPIO of the modules.   Patches: Create V4L2 device enabling the capture of by the ISI of DC loop-backs. Enable ISI capture from DSI 0 / LVDS 1 in 1920x1080 (at the same time.) Enable ISI capture from HDMI in 2840x2160 (half with even pixel) in 1920x2160. While capturing with the ISI, the captured screen continue to be displayed. Remark: Ov5640 cameras are also enabled in the same dtb. So 4 stream in 1920x1080 can be captured at the same time. Installation and gstreamer command: See readme

       

     

This is a detailed programming aid for the registers associated with i.MX 8MMini (m845S) DDR initialization.  For more details, refer to the main mScale DDR tools page: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX-8M-Family-DDR-Tool-Release/ta-p/1104467 Please note that this page is only intended to store the RPA spreadsheets. For questions, please create a new community thread.

This is a detailed programming aid for the registers associated with i.MX 8M (m850D) DDR initialization.  For more details, refer to the main mScale DDR tools page: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX-8M-Family-DDR-Tool-Release/ta-p/1104467 Please note that this page is only intended to store the RPA spreadsheets. For questions, please create a new community thread.

Important: If you have any questions or would like to report any issues with the DDR tools or supporting documents please create a support ticket in the i.MX community. Please note that any private messages or direct emails are not monitored and will not receive a response.   This is a detailed programming aid for the registers associated with i.MX 8/8X DDR initialization.  For more details, refer to the i.MX 8/8X main DDR tools page: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX-8-8X-Family-DDR-Tools-Release/ta-p/1121519 Note: Devices with 17-row addresses (R0-R16) are not supported by this SoC.  To reduce the number of attachments, older RPAs may be found in the attached zip file.   ***IMPORTANT: For SCFWv1.7.0, you must use the following RPA versions or later: MX8QM_B0_LPDDR4_RPA_1.6GHz_v23 Older versions of the RPA are not aligned to SCFWv1.7.0.  If trying to use an older version of an RPA with SCFWv1.7.0, it will cause the SCFW not to boot.  The offending lines in the DCD output are as follows: For MX8QM: DATA 4 0xff148000 0x00000885 /* DRC0 bringup */ DATA 4 0xff1a0000 0x00000885 /* DRC1 bringup */ If the user wishes to use an older RPA with SCFW 1.7.0 (not recommended), then the above lines must be removed from older RPA DCD file outputs.  In addition, wrapping these lines are "#ifndef SCFW_DCD", "#else", and "#endif" preprocessor commands.  These should be removed as well.  For example of MX8QM: [remove] #ifndef SCFW_DCD [remove] /* For 1600MHz DDR, DRC 800MHz operation */ [remove] DATA 4 0xff148000 0x00000885 /* DRC0 bringup */ [remove] DATA 4 0xff1a0000 0x00000885 /* DRC1 bringup */ [remove] #else <keep code as is> [remove] #endif  

Important: If you have any questions or would like to report any issues with the DDR tools or supporting documents please create a support ticket in the i.MX community. Please note that any private messages or direct emails are not monitored and will not receive a response.   This is a detailed programming aid for the registers associated with i.MX 8/8X DDR initialization.  For more details, refer to the i.MX 8/8X main DDR tools page: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX-8-8X-Family-DDR-Tools-Release/ta-p/1121519   To reduce the number of attachments, older RPAs may be found in the attached zip file. Note: Devices with 17-row addresses (R0-R16) are not supported by this SoC.  ***IMPORTANT: For SCFWv1.7.0 and later, you must use the following RPA versions or later: MX8QXP_C0_B0_LPDDR4_RPA_1.2GHz_v16 MX8DualX_C0_B0_LPDDR4_RPA_1.2GHz_v16 MX8QuadXPlus_DualXPlus_C0_B0_DDR3L_RPA_v22 MX8DualX_C0_B0_DDR3L_RPA_v20 Older versions of the RPA are not aligned to SCFWv1.7.0 and later.  If trying to use an older version of an RPA with SCFWv1.7.0, it will cause the SCFW not to boot.  The offending lines in the DCD output are as follows: For MX8QXP/DualX: DATA 4 0xff190000 0x00000CC8 /* DRC0 bringup */ If the user wishes to use an older RPA with SCFW 1.7.0 and later (not recommended), then the above lines must be removed from older RPA DCD file outputs.  In addition, wrapping these lines are "#ifndef SCFW_DCD", "#else", and "#endif" preprocessor commands.  These should be removed as well.  For example of MX8QXP: [remove] #ifndef SCFW_DCD [remove] -/* For 1200MHz DDR, DRC 600MHz operation */ [remove] DATA 4 0xff190000 0x00000CC8 /* DRC0 bringup */ [remove] #else <keep code as is> [remove] #endif

Harware: - i.MX7D-SDB board - QCA9880 card with MINI PCIe Interface The Wifi module is connected to the PCIe slot on the board.     Software: - Ubuntu 18.04 LTS Host - L4.19.35_1.1.0 BSP   Tool: - uuu 1.2.68 for linux (run on ubuntu host)   Toolchain: - The toolchain can be obtained from the Yocto BSP. Please read and follow the steps in i.MX_Yocto_Project_User's_Guide to build the BSP and then read the Chapter of "How to build U-Boot and Kernel in standalone environment" in i.MX_Linux_User's_Guide to build the toolchain.   Build the Kernel: # mkdir imx_build # cd imx_build # git clone https://source.codeaurora.org/external/imx/linux-imx -b imx_4.19.35_1.1.0 # cd linux-imx # source /opt/fsl-imx-fb/4.19-warrior/imx6/environment-setup-cortexa9hf-neon-poky-linux-gnueabi # export ARCH=arm # make clean # make imx_v7_defconfig # make menuconfig - Select the PCIe driver and the Wifi support - PCI controller drivers--->                    DesignWare PCI Core Support----> - Networking support----->                             Wireless----->   - Select the ath10 driver (it supports QCA988X) Device Drivers---->             Network device support----->                                      Wirless LAN----> - Save and Exit. - Add the firmware in the .config file: Get the firmware file (e.g. firmware-2.bin) from your wifi vendor or download it from the web. Put the firmware in linux-imx/firmware/ folder. Edit the .config file and add these two lines: CONFIG_EXTRA_FIRMWARE="board.bin firmware-2.bin" CONFIG_EXTRA_FIRMWARE_DIR="/home/jimmy/imx_build/linux-imx/firmware" - Build the kernel # make Then the zImage will be obtained in arch/arm/boot.   Using uuu to program the SD card: - Downloading demo image of L4.19.35_1.10 from the nxp website. - Copy the zImage to the directory - Copy the uuu (V1.2.68) to the directory - Copy the samples/example_kernel_emmc.uuu to imx7d_kernel_emmc.uuu - Modify the image the imx7d_kernel_emmc.uuu - In the demo image, you will see the files like this: - run uuu and the script to program the images.   Wifi driver loaded and wlan0 is up: # dmesg | grep pci   # ifconfig -a   Reference Document: - i.MX_Linux_User's_Guide.pdf - i.MX_Porting_Guide.pdf  

To enable USB 2.0 port on BB for USB OTG, you need to apply below two changes: device/fsl.git   diff --git a/imx8q/mek_8q/init.usb.rc b/imx8q/mek_8q/init.usb.rc index af4e388..0f3ab0b 100644 --- a/imx8q/mek_8q/init.usb.rc +++ b/imx8q/mek_8q/init.usb.rc @@ -44,7 +44,7 @@ on early-boot      mount functionfs mtp /dev/usb-ffs/mtp rmode=0770,fmode=0660,uid=1024,gid=1024,no_disconnect=1      mount functionfs ptp /dev/usb-ffs/ptp rmode=0770,fmode=0660,uid=1024,gid=1024,no_disconnect=1      setprop sys.usb.mtp.device_type 3 -    setprop vendor.usb.config "5b110000.usb3" +    setprop vendor.usb.config "ci_hdrc.0"      write /sys/module/libcomposite/parameters/disable_l1_for_hs "y"      symlink /config/usb_gadget/g1/configs/b.1 /config/usb_gadget/g1/os_desc/b.1   vendor/nxp-opensource/kernel_imx.git           revert below patch:           commit 2f9586c120971312e61df464264993899cf34536           Author: yang.tian <[email protected]>           Date:   Tue Jan 7 13:30:02 2020 +0800       MA-15242 Set usb2.0 port as usb host only for mek_8q  

1. HW Environment:     IMX8mp-evk board.     ITE6151 mipi dsi to eDP bridge board.   2. SW Environment:     IMX YOCTO 5.4.24-2.1.0 release.   3. Patch operation:     a. git clone https://source.codeaurora.org/external/imx/linux-imx.git     b. git checkout -b  imx_5.4.24_2.1.0 origin/imx_5.4.24_2.1.0     c. patch -p1 < ../ite6151_mipi2edp_linux_5.4.24_20200921.patch   4. Tested on imx8mp-evk board with DP monitor on 1080p mode: 5. Attached doc list:     IT6151 demo board user guide v1.0.pdf ------  ite6151 bridge board HW guide     it6151_qfn48_v20_20190905-01_end.pdf  ------  ite6151 bridge board SCH     imx8mp_ite6151_mipi2edp_linux_5.4.24_20200921.patch ------  Linux kernel driver patch     Image + imx8mp-evk-it6151.dtb  ------  test image and dtb  

After following instructions on how to change DRAM PLL frequency, here is a quick comparison of Stream, running on the i.MX 8MM. Normalized to LPDDR4-3000, based on 5.4.24_2.1.0​ BSP Stream LP4-3000 LP4-2400 DDR4-2400 LPDDR-1866 Copy: 1 0.810 0.735 0.497 Scale: 1 0.896 0.765 0.756 Add: 1 0.899 0.683 0.762 Triad: 1 0.902 0.680 0.767      

The i.MX8QuadMax SMARC System On Module integrates Dual Cortex A72 + Quad Cortex A53 Cores, Dual GPU systems, 4K H.265 capable VPU dual failover-ready display controller based i.MX8 QuadMax SoC with on SOM Dual 10/100/1000 Mbps Ethernet PHY, USB 3.0 hub and IEEE 802.11a/b/g/n/ac Wi-Fi & Bluetooth 5.0 module.

Hi all !      I found a problem, wiif connection issue .  When I connect to WiFi hotspots, reported a warning ！     <4>RTL871X: assoc success <4>------------[ cut here ]------------ <4>WARNING: at net/wireless/sme.c:482 __cfg80211_connect_result+0x2f4/0x32c() <4>Modules linked in: 8188eu <4>[<c0054044>] (unwind_backtrace+0x0/0x138) from [<c008c1b8>] (warn_slowpath_common+0x4c/0x64) <4>[<c008c1b8>] (warn_slowpath_common+0x4c/0x64) from [<c008c1ec>] (warn_slowpath_null+0x1c/0x24) <4>UpdateHalRAMask8188EUsb => mac_id:0, networkType:0x0b, mask:0x000fffff <4>     ==> rssi_level:0, rate_bitmap:0x000ff015 <4>[<c008c1ec>] (warn_slowpath_null+0x1c/0x24) from [<c069e3a0>] (__cfg80211_connect_result+0x2f4/0x32c) <4>[<c069e3a0>] (__cfg80211_connect_result+0x2f4/0x32c) from [<c06893f4>] (cfg80211_process_rdev_events+0x1e0/0x204) <4>[<c06893f4>] (cfg80211_process_rdev_events+0x1e0/0x204) from [<c0686ec0>] (cfg80211_event_work+0x24/0x54) <4>[<c0686ec0>] (cfg80211_event_work+0x24/0x54) from [<c00a66f0>] (process_one_work+0x12c/0x494) <4>[<c00a66f0>] (process_one_work+0x12c/0x494) from [<c00a6bc8>] (worker_thread+0x170/0x3cc) <4>[<c00a6bc8>] (worker_thread+0x170/0x3cc) from [<c00aacbc>] (kthread+0x80/0x88) <4>[<c00aacbc>] (kthread+0x80/0x88) from [<c004d408>] (kernel_thread_exit+0x0/0x8) <4>---[ end trace 14efbc2d6eba2439 ]---       This document was generated from the following discussion: 

Important: If you have any questions or would like to report any issues with the DDR tools or supporting documents please create a support ticket in the i.MX community. Please note that any private messages or direct emails are not monitored and will not receive a response.   These are the detailed programming aids for the registers associated with MMDC DDR3 and LPDDR2 initialization for the MX6DQ SoC. The last sheet formats the register settings for use with ARM RealView ICE. It can also be used with the windows executable for the DDR Stress Test. This programming aid was used for internal NXP boards.  

I have finally been able to get multi MSI (not MSI-X) working on the i.MX6 using the Linux kernel v4.1.15 release supported by Freescale/NXP. Attached are four patches which will need to be applied. This has been tested with two different end point FPGA devices with the i.MX6 running in root complex, I can confirm that multi MSI is now working.   Freescale/NXP: Please put these patches in your supported main line so others can have native multi MSI support.   You may have to contact your board manufacturer to find where within Yocto you will need to store these patches. If just building the kernel outside of Yocto then you can directly apply them.   The four kernel (v4.1.15) files which need to be patched are: <kernel source path>/include/linux/msi.h <kernel source path>/drivers/pci/msi.c <kernel source path>/drivers/pci/host/pcie-designware.h <kernel source path>/drivers/pci/host/pcie-designware.c   Once the above patches are applied and you create a new image/build you can start using the multi MSI APIs in your driver and pci_msi_vec_count() and pci_enable_msi_range() will work; this assumes your end point device on the PCIe link is working correctly.   Hopefully this is helpful to those who need multi MSI.   This document was generated from the following discussion: SOLVED: i.MX6 and Multi MSI Working

Attached is the Kernel image needed to construct the Linux Image i.MX 6Dual/6Quad Power Consumption Measurement Linux Image

Add SSI_ASRC_P2P support for imx6 based on Kernel 3.0.35.

The i.MX 6 D/Q/DL/S/SL Linux 3.10.53_1.1.0 GA release is now available on www.freescale.com ·         Files available           Name Description L3.10.53_1.1.0_LINUX_DOCS i.MX 6 D/Q/DL/S/SL Linux   3.10.53_1.1.0 GA BSP documentation. L3.10.53_1.1.0_iMX6QDLS_Bundle i.MX 6 D/Q/DL/S  Linux   3.10.53_1.1.0 GA BSP Binary Demo Files L3.10.53_1.1.0_iMX6SL_Bundle i.MX 6 SL  Linux   3.10.53_1.1.0 GA BSP Binary Demo Files L3.10.53_1.1.0_AACP_CODECS AAC Plus Codec for the i.MX 6 D/Q/DL/S/SL Linux 3.10.53_1.1.0   GA BSP y IMX_6_MFG_L3.10.53_1.1.0_TOOL Manufacturing Tool and Documentation for Linux   3.10.53_1.1.0 GA BSP y ·         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 o   i.MX6SL EVK board New Features ·                             Please refer to formal Release Note document for all details. Known issues For known issues and limitations please consult the release notes located in the BSP documentation package.

Creating an image A kernel image and a root file system can be created using LTIB, or compiling the kernel and setting the correct set of files. Create a root file system image from a set of files converting the files to a jffs2 file system. For this, install the package mtd-tools. In Ubuntu type apt-get install mtd-tools For making an root file system for flash, use the jffs2 file system like: mkfs.jffs2 -r rootfs -e 0x40000 -s 0x800 -n -o rootfs.jffs2 Where rootfs/ is the original set of file for the file system and rootfs.jffs2 is the output image file. Flashing Some connection errors can be avoided by Configuring RedBoot. The process below uses TFTP to copy the files between host and target. Copy the kernel image and the root file system image to the TFTP dir. For example, in All Boards LTIB dir, type sudo cp ./rootfs/boot/zImage /tftpboot sudo cp rootfs.jffs2 /tftpboot/ Where /tftpboot is the dir configured for TFTP The next steps are performed in a Minicom session, and happens on the board. Formatting the flash: fis init Flashing kernel Load kernel image (zImage) using the command below. Remember to modify the host IP address: load -r -b 0x100000 /tftpboot/zImage -h 10.29.244.99 The address 0x100000 is used as a temporary location Create the kernel fis create -f 0x100000 kernel Flashing root file system Load root file system image (rootfs.jffs2) to the temporary address. Remember to modify the host IP address: load -r -b 0x100000 /tftpboot/rootfs.jffs2 -h 10.29.244.99 Create the root file system in the right address (0x600000, for i.MX35 PDK) fis create -f 0x600000 root You can now load your kernel in the flash by typing: fis load kernel To know if the root file system written in the flash was correctly saved, execute the NFS file system and mount the flash. For load the the root file system by NFS, type: exec -b 0x100000 -l 0x200000 -c "noinitrd console=ttymxc0,115200 root=/dev/nfs nfsroot=10.29.244.99:/tftpboot/ltib init=/linuxrc ip=10.29.241.6:10.29.244.99" Wait the system go up, then mount the flash at /mnt. Reminde that the flash has a jffs2 file system. mount -t jffs2 /dev/mtdblock8 /mnt ls /mnt List the /mnt contents. The output must be the right file system. Modifying the initial script Reset the board and press CTRL-C. Type fc to modify the configurations and insert the initialization script. RedBoot> fc Run script at boot: true Boot script: Enter script, terminate with empty line >> fis load kernel >> exec -c "noinitrd console=ttymxc0,115200 root=/dev/mtdblock8 rw rootfstype=jffs2 ip=dhcp" >> Boot script timeout (1000ms resolution): 1 Use BOOTP for network configuration: false Gateway IP address: 10.29.241.254 Local IP address: 10.29.241.6 Local IP address mask: 255.255.254.0 Default server IP address: 10.29.244.99 Board specifics: 0 Console baud rate: 115200 Set eth0 network hardware address [MAC]: false GDB connection port: 9000 Force console for special debug messages: false Network debug at boot time: false Update RedBoot non-volatile configuration - continue (y/n)? y ... Read from 0x07ee0000-0x07eff000 at 0x00080000: . ... Erase from 0x00080000-0x000a0000: . ... Program from 0x07ee0000-0x07f00000 at 0x00080000: . RedBoot> Remember to save the configuration in the flash by typing y Reset the system. To certify that the board is loading the system from flash, remove the Ethernet cable.

1. Increasing the number of threads. Make sure the Parallelism variables located on conf/local.conf BB_NUMBER_THREADS: indicating how many task bitbake should run in parallel PARALLEL_MAKE: indicating how many processes make should run in parallel are not commented and with correct values. The script  setup-enviroment  automatically sets these equal to the number of CPU cores. You can double this value if you want but there is no significant speed's gain. 2. Having a local repository on the server. When baking an image, one of the first steps for each recipe is to fetch the source code (from git repos, tarballs, etc); it makes sense to reuse this data for future builds and also share it with other server's users. You can indicate bitbake to look first at a local repo (file://) on your conf/local.conf file SOURCE_MIRROR_URL ?= "file:///opt/yocto/download/" INHERIT += "own-mirrors" BB_GENERATE_MIRROR_TARBALLS = "1" # BB_NO_NETWORK = "1" Just make sure the download folder has read access for all users (chmod a+r /opt/yocto/download/)