i.MX Processors Knowledge Base

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX Processors Knowledge Base

Discussions

Sort by:
www.nxp.com公网资源 .............................................. 2 1.1 www.nxp.com Documentation ................................ 3 1.2 www.nxp.com Tools&Software ............................... 7 2 nxp share point资源(仅对有访问权限客户开放) ....... 14 2.1 i.MX 8X Family Board, Software POR and How to Purchase ...................................................................... 14 2.2 Development Platforms ........................................ 14 2.3 Device Dcoumentation ......................................... 15 2.4 Security Reference Manual .................................. 16 2.5 Software Documentation ...................................... 16 3 nxp 社区资源 ........................................................... 16
View full article
Default Ethernet feature is removed for Android Auto (both Android_Pie9.0 and Android10) Below are the patched to bring Ethernet feature back to Android Auto. Please try to apply the according patches if you want to enable Ethernet. For Android_Pie9.0_Auto(example with car2 build): --- a/arch/arm64/configs/android_car2_defconfig +++b/arch/arm64/configs/android_car2_defconfig @@ -245,7 +245,7 @@ CONFIG_DM_VERITY_FEC=y CONFIG_NETDEVICES=y CONFIG_MACVTAP=m CONFIG_TUN=y -# CONFIG_ETHERNET is not set +CONFIG_ETHERNET=y CONFIG_MDIO_BUS_MUX_MMIOREG=m CONFIG_AT803X_PHY=m CONFIG_MARVELL_PHY=m @@ -517,7 +517,7 @@ CONFIG_SQUASHFS=y CONFIG_SQUASHFS_DECOMP_MULTI=y CONFIG_SQUASHFS_XATTR=y CONFIG_SQUASHFS_LZ4=y -# CONFIG_NETWORK_FILESYSTEMS is not set +CONFIG_NETWORK_FILESYSTEMS=y   --- a/imx8q/mek_8q/mek_8q.mk +++ b/imx8q/mek_8q/mek_8q.mk @@ -46,6 +46,7 @@ PRODUCT_COPY_FILES += \      $(IMX_DEVICE_PATH)/fstab.freescale.car:$(TARGET_COPY_OUT_VENDOR)/etc/fstab.freescale \      $(IMX_DEVICE_PATH)/early.init_car.cfg:$(TARGET_COPY_OUT_VENDOR)/etc/early.init.cfg \      $(IMX_DEVICE_PATH)/required_hardware_auto.xml:$(TARGET_COPY_OUT_VENDOR)/etc/permissions/required_hardware.xml \ +    frameworks/native/data/etc/android.hardware.ethernet.xml:$(TARGET_COPY_OUT_VENDOR)/etc/permissions/android.hardware.ethernet.xml \      device/fsl/imx8q/init.recovery.freescale.car.rc:root/init.recovery.freescale.rc   For Android10_Auto,(example with car build): --- a/arch/arm64/configs/android_car_defconfig +++ b/arch/arm64/configs/android_car_defconfig @@ -23,6 +23,8 @@ CONFIG_SCHED_AUTOGROUP=y CONFIG_SCHED_TUNE=y CONFIG_RELAY=y CONFIG_BLK_DEV_INITRD=y +CONFIG_FEC=y +CONFIG_AT803X_PHY=y # CONFIG_RD_BZIP2 is not set # CONFIG_RD_LZMA is not set # CONFIG_RD_XZ is not set @@ -246,7 +248,6 @@ CONFIG_DM_VERITY=y CONFIG_DM_VERITY_FEC=y CONFIG_NETDEVICES=y CONFIG_TUN=y -# CONFIG_ETHERNET is not set   --- a/imx8q/mek_8q/mek_8q.mk +++ b/imx8q/mek_8q/mek_8q.mk @@ -46,6 +46,7 @@ PRODUCT_COPY_FILES += \      $(IMX_DEVICE_PATH)/fstab.freescale.car:$(TARGET_COPY_OUT_VENDOR)/etc/fstab.freescale \      $(IMX_DEVICE_PATH)/early.init_car.cfg:$(TARGET_COPY_OUT_VENDOR)/etc/early.init.cfg \      $(IMX_DEVICE_PATH)/required_hardware_auto.xml:$(TARGET_COPY_OUT_VENDOR)/etc/permissions/required_hardware.xml \ +    frameworks/native/data/etc/android.hardware.ethernet.xml:$(TARGET_COPY_OUT_VENDOR)/etc/permissions/android.hardware.ethernet.xml \      device/fsl/imx8q/init.recovery.freescale.car.rc:root/init.recovery.freescale.rc   Note: Please also check for below file, if fec1 is disabled, please also apply below diff. --- a/arch/arm64/boot/dts/freescale/imx8qm-mek-car2.dts +++ b/arch/arm64/boot/dts/freescale/imx8qm-mek-car2.dts @@ -147,10 +147,6 @@ status = "disabled"; }; -&fec1 { - status = "disabled"; -}; - &fec2 { status = "disabled"; };
View full article
Click to view the webinar recording View More Information and Order the Vision Starter Kit
View full article
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.
View full article
         This document will describe how to add open JDK to i.MX yocto BSP. It will take two versions of Linux BSP as an example, one is the lower version of L4.1.15-2.0.0, the other is the latest version of L4.19.35-1.1.0. Adding openjdk-8 to L4.1.15-2.0.0(Ubuntu 16.04 LTS platform) Before adding an open JDK, you must download L4.1.15-2.0.0 BSP according to the i.MX_Yocto_Project_User's_Guide.pdf, and ensure that it can pass the compilation normally, that is to say, there is no error in the compilation. In this example, BSP is compiled using the following command. # DISTRO=fsl-imx-wayland MACHINE=imx6sxsabresd source fsl-setup-release.sh -b build-wayland # bitbake fsl-image-qt5          Then follow the steps below to add openjdk to the yocto layer:   Fetching openjdk-8 from Yocto website # cd ~/imx-release-bsp # cd sources # git clone git://git.yoctoproject.org/meta-java # cd meta-java # git checkout -b krogoth origin/krogoth  [Comment]    Yocto’s version is described in i.MX_Yocto_Project_User's_Guide.pdf 2. Modifying related configurations (1) build-wayland/conf/local.conf Add following lines to the file: # Possible provider: cacao-initial-native and jamvm-initial-native PREFERRED_PROVIDER_virtual/java-initial-native = "cacao-initial-native" # Possible provider: cacao-native and jamvm-native PREFERRED_PROVIDER_virtual/java-native = "cacao-native" # Optional since there is only one provider for now PREFERRED_PROVIDER_virtual/javac-native = "ecj-bootstrap-native" IMAGE_INSTALL_append = " openjdk-8" Save it and exit (2)build-wayland/conf/bblayers.conf Add java layer to the file, like below: BBLAYERS = " \   ${BSPDIR}/sources/poky/meta \   ${BSPDIR}/sources/poky/meta-poky \   \   ${BSPDIR}/sources/meta-openembedded/meta-oe \   ${BSPDIR}/sources/meta-openembedded/meta-multimedia \   \   ${BSPDIR}/sources/meta-fsl-arm \   ${BSPDIR}/sources/meta-fsl-arm-extra \   ${BSPDIR}/sources/meta-fsl-demos \   ${BSPDIR}/sources/meta-java \ "…… Save it and exit. 3. Build openjdk-8 # cd ~/imx-release-bsp # source setup-environment build-wayland #bitbake openjdk-8 -c fetchall          Fetch all packages related to openjdk-8. [error handling]          During downloading packages, you may encounter errors like the following. (1)Fetch fastjar-0.98.tar.gz errors          The error is caused by invalid web address, we can download it from another link, see below: http://savannah.c3sl.ufpr.br/fastjar/fastjar-0.98.tar.gz copy the link to firefox in Ubuntu platform, and it will be downloaded into ~/Downloads # cd ~/imx-release-bsp/downloads # cp ~/Downloads/ fastjar-0.98.tar.gz ./ # touch fastjar-0.98.tar.gz.done   (2)Fetch “classpath-0.93.tar.gz” error          Download it from : http://mirror.nbtelecom.com.br/gnu/classpath/classpath-0.93.tar.gz And copy it to ~/imx-release-bsp/downloads, and create a file named classpath-0.93.tar.gz.done in the directory. # cd ~/imx-release-bsp/downloads # cp ~/Downloads/ classpath-0.93.tar.gz ./ # touch classpath-0.93.tar.gz.done (3) 8 files with tar.bz2 (hotspot-Java jvm)          These similar errors are very likely to be encountered.          These errors are caused by the bad network environment. You can download these packages manually. These are Java virtual machine source packages, i.e. hotspot JVM [Solution] # mkdir ~/temp # cd temp # wget http://www.multitech.net/mlinux/sources/56b133772ec1.tar.bz2 # wget http://www.multitech.net/mlinux/sources/ac29c9c1193a.tar.bz2 # wget http://www.multitech.net/mlinux/sources/1f032000ff4b.tar.bz2 # wget http://www.multitech.net/mlinux/sources/81f2d81a48d7.tar.bz2 # wget http://www.multitech.net/mlinux/sources/0549bf2f507d.tar.bz2 # wget http://www.multitech.net/mlinux/sources/0948e61a3722.tar.bz2 # wget http://www.multitech.net/mlinux/sources/48c99b423839.tar.bz2 # wget http://www.multitech.net/mlinux/sources/bf0932d3e0f8.tar.bz2          Then create .tar.bz2.done files for each package via touch command   # touch 56b133772ec1.tar.bz2.done # touch ac29c9c1193a.tar.bz2.done # touch 1f032000ff4b.tar.bz2.done # touch 81f2d81a48d7.tar.bz2.done # touch 0549bf2f507d.tar.bz2.done # touch 0948e61a3722.tar.bz2.done # touch 48c99b423839.tar.bz2.done # touch bf0932d3e0f8.tar.bz2.done          Like below:          Then copy these files to ~/ fsl-release-bsp/downloads/ # bitbake openjdk-8 -c compile          After openjdk compilation, you will be prompted as follows:          At last , install openjdk-8 to images # bitbake fsl-image-qt5          Done: [Additional description]          The above method of adding openjdk-8 is the steps after BSP compilation. Users can also add openjdk-8 before BSP compilation, and then compile it with BSP          According to steps in i.MX_Yocto_Project_User's_Guide.pdf, After running the following two commands, users can modify bblayers.conf and local.conf directly.          For example, steps below have been validated: … … # repo sync # cd ~/fsl-release-bsp # DISTRO=fsl-imx-x11 MACHINE=imx6qsabresd source fsl-setup-release.sh -b build-x11 # gedit ./conf/bblayers.conf          Add the same contents as above. # gedit ./conf/local.conf          Add the same contents as above. # bitbake fsl-image-gui          During compilation, users may encounter some errors, which can be handled by referring to the methods described above Adding openjdk-8 to L4.19.35-1.1.0(Ubuntu 18.04 LTS Platform) In fact, the steps to add openjdk-8 to l4.19.35 are the same as those described above, and the following steps have been verified. Before adding openjdk-8, i.mx8qxp full image has been compiled with 2 commands below, so we only need to add openjdk-8 here. # DISTRO=fsl-imx-xwayland MACHINE=imx8qxpmek source fsl-setup-release.sh -b build-xwayland # bitbake imx-image-full # cd sources # git clone git://git.yoctoproject.org/meta-java # cd meta-java # git checkout -b warrior origin/warrior          Release L4.19.35_1.1.0 is released for Yocto Project 2.7 (Warrior). # cd ~/imx-release-bsp-l4.19.35 # source setup-environment build-xwayland-imx8qxpmek # gedit ./conf/bblayers.conf          Add meta-java to it.          ……            ${BSPDIR}/sources/meta-java \          ……          Save and exit. # gedit ./conf/local.conf          Add these lines to it.          # Possible provider: cacao-initial-native and jamvm-initial-native PREFERRED_PROVIDER_virtual/java-initial-native = "cacao-initial-native" # Possible provider: cacao-native and jamvm-native PREFERRED_PROVIDER_virtual/java-native = "cacao-native" # Optional since there is only one provider for now PREFERRED_PROVIDER_virtual/javac-native = "ecj-bootstrap-native" IMAGE_INSTALL_append = " openjdk-8" Save and exit.   # cd ~/imx-release-bsp-l4.19.35/build-xwayland-imx8qxpmek # bitbake openjdk-8 -c fetch # bitbake openjdk-8 -c compile [Errors] [Solution] # gedit ./ tmp/work/x86_64-linux/openjdk-8-native/172b11-r0/jdk8u-33d274a7dda0/hotspot/make/linux/Makefile Comment the following lines: ----------------------------------------- check_os_version: #ifeq ($(DISABLE_HOTSPOT_OS_VERSION_CHECK)$(EMPTY_IF_NOT_SUPPORTED),) #       $(QUIETLY) >&2 echo "*** This OS is not supported:" `uname -a`; exit 1; #endif -----------------------------------------          Then continue # cd ~/imx-release-bsp-l4.19.35/build-xwayland-imx8qxpmek # bitbake openjdk-8 -c compile [comment]          Probably similar errors will be encountered during compiling other packages, we can use the same way like above to solve it, see bellow, please! Done:          At last, install openjdk-8 to images. # bitbake imx-image-full          Installation is done. NXP TIC Team  Weidong Sun 12/31/2019
View full article
This doc show: on i.MX8QXP MEK board, configure ov5640 sensor(parallel interface) output 5MP(2592x1944) RAW(Bayer) data at 15fps, and Parallel Capture Subsystem and Image Sensor Interface capture RAW RGB data, and i.MX8QXP GPU debayer RAW data then display image. HW: i.MX8QXP MEK board, MEK base board (to place the parallel camera), ov5640 sensor. SW: Linux 4.14.98_2.0.0 BSP, and patches in this doc.   Configure at camera sensor side A Bayer filter is a color filter array (CFA) for arranging RGB color filters on a square grid of photosensors. The filter pattern is 50% green, 25% red and 25% blue, hence is also called BGGR, RGBG ,GRGB, or RGGB. The ov5640 has an image array capable of operating at up to 15 fps in 5 megapixel (2592x1944) resolution. OV5640 support output formats: RAW(Bayer), RGB565/555/444,CCIR656, YUV422/420, YCbCr422, and compression. To make ov5640 output 5MP RAW data at 15fps, check my kernel patch imx8-ov5640-raw-capture-driver-4.14.98_2.0.0.diff which apply on i.MX Linux 4.14.98_2.0.0 BSP kernel code. Parallel interface ov5640, use ov5640_raw_setting[] array of drivers/media/platform/imx8/ov5640_v3.c. This register setting is come from ov5640 software application note and data sheet. Configure at i.MX8QXP side The Parallel Capture Subsystem consists of the Parallel Capture Interface (BT 656) and associated peripherals. It interfaces to the Parallel CSI sensor. This allows for up to 24 RGB data bits in parallel or for RGB components on consecutive clocks (up to 10-bit color depth). The formats supported are RGB, RAW and YUV 422. Below is Parallel Capture Subsystem diagram: For RAW format data, CSI_CTRL_REG of Parallel Capture Subsystem need configured as my patch, otherwise found cannot get correct data.   The multiple input sources (MIPI CSI, Parallel Capture) captures the pixel data and feeds it to the ISI. The ISI is responsible for capturing and pre-processing the pixel data from multiple input sources and storing them into the memory. Below is ISI diagram: For RAW format data, it should be bypass any processing pipeline of ISI, just use ISI to save it to memory.   Capture test code To capture the RAW data and save it to file, check my patch imx8_ov5640_raw_captupre_test_4.14.98_2.0.0_ga.diff which apply on i.MX Linux 4.14.98_2.0.0 BSP unit test code. Note the usage is: ./imx8_cap.out -of -cam 1 -fr 15 -fmt BA81 -ow 2592 -oh 1944 -num 100   Display RAW data The RAW data cannot be displayed directly, debayer process is needed to get complete red, green, blue color for each pixel. The debayer process if run on CPU, will cost much CPU time. To save CPU time, debayer could done by GPU. The method is, captured RAW data upload to GPU as texture , then GPU will do the debayer, then full color of each pixel will be got, then display it. To upload RAW camera data to GPU with zero memory copy, i will use i.MX8QXP GPU extension GL_VIV_direct_texture. It create a texture with direct access support. API glTexDirectVIVMap,  which support mapping a user space memory or a physical address into the texture surface. The API glTexDirectVIVMap need logic and physical address of data buffer, so i will allocate data buffer from g2d lib, it is dma-buffer also get logic/physical address of buffer, then queue it as DMABUF to v4l2 capture driver, after dequeue got RAW camera data, pass it to GPU for debayer. GPU side, I will use OpenGL shader code from "Efficient, High-Quality Bayer Demosaic Filtering on GPUs". Check my patch imx8_debayer-gpusdk-5.3.0.diff which apply on i.MX GPU SDK 5.3.0 code. Note, here i only do is debayer, no extra process.   Known issue One thing is ov5640 output 5MP at 15fps, compare with output 5MP at 5fps, there are more noise of camera data at 15fps case. My debug found is, this noise seems come from ov5640 itself.   Reference: a>https://www.nxp.com/webapp/Download?colCode=IMX8DQXPRM b>https://www.nxp.com/webapp/Download?colCode=L4.14.98_2.0.0_MX8QXP&appType=license c>https://github.com/NXPmicro/gtec-demo-framework d>ov5640 data sheet e>ov5640 software application note f>Efficient, High-Quality Bayer Demosaic Filtering on GPUs https://www.semanticscholar.org/paper/Efficient%2C-High-Quality-Bayer-Demosaic-Filtering-on-McGuire/088a2f47b7ab99c78d41623bdfaf4acdb02358fb
View full article
Platform: i.mx8qm/qxp OS: imx-yocto-L4.14.98_2.0.0_ga Camera: max9286 deserializer <=> max96705 serializer  + ar0144 or: max9286 deserializer <=> max96705 serializer + ov9284 Note that currently only one camera is support and the serializer should be connected to the IN0 of max9286. Data format: ar0144: mono raw 12bit. ov9284: mono raw 10bit. On imx8qm/qxp the data will be recieved as raw 16bit and the valid data bit start from bit[13] to LSB. for mono raw 12bit the valid data bit is 0bxxdd_dddd_dddd_ddxx for mono raw 10bit the valid data bit is 0bxxdd_dddd_dddd_xxxx max9286 and max96705 configuration: dbl bws PXL_CRC/edc hven hibw lccen him should be the same on both sides, this can be achieved by pin or register configurations. The crossbar function of max96705 can be used to fix the reversed data bit. for example, reversed 12bit with dbl to 1. 0x20 0xb 0x21 0xa 0x22 0x9 ....... 0x2b 0x0 0x30 0xb 0x31 0xa .... 0x3b 0x0 0x20 to 0x2b and 0x30 to 0x3b are the registers of max96705. Patch apply: 1. push the kernel-patch to the kernel source and apply it. 2. reconfig the kernel setting, make sure there is only CONFIG_MAX9286_AR0144 or        CONFIG_MAX9286_WISSEN(ov9284) enabled, all other max9286 related are disabled. You can run menuconfig to achieve this. 3. For testing copy the vulkan-v4l2.tar to the board, and run vulkan-v4l2.     the source code is at https://github.com/sheeaza/vulkan-v4l2 branch ar0144 for ar0144, branch ov9284 for ov9284. =========== updated patch for data format.
View full article
Most i.MX8QXP/QM customers already work on L4.14.98 GA for their Auto product, like C-V2X TBOX, Car infortainment system. Some customers also want to adopt OP-TEE in their security design, but OP-TEE on i.MX8QXP/QM platform don't support HW cryptography accelerating which base on CAAM module. So I worked on the issue last week and fixed it. The package meta-optee-add-on_4.14.98_2.0.0_ga.tgz is Yocto layer which includes all patches for fixing the issue. Software environments as the belows: Linux kernel: imx_4.14.98_2.0.0_ga HW platform:  i.MX8QM/QXP MEK. How to build: 1, decompress meta-optee-add-on_4.14.98_2.0.0_ga.tgz and copy meta-optee-add-on to folder (Yocto 4.14.98_2.0.0_ga dir)/sources/ 2, Run DISTRO=fsl-imx-wayland MACHINE=imx8qxpmek source fsl-setup-release.sh -b build-optee and add BBLAYERS += " ${BSPDIR}/sources/meta-optee-add-on " into (Yocto 4.14.98_2.0.0_ga dir)/build-optee/conf/bblayers.conf  3, Run bitbake fsl-image-validation-imx. 4, You can run xtest or xtest -l 1 4007 on your MEK board to test optee crypto feature after completing build image. You can find it only take about one second comparing no CAAM accelerating when test "regression_4007.11 Generate RSA-2048 key".
View full article
恩智浦BSP的内核定制 ........................................... 103 6.1 IO管脚配置与Pinctrl驱动 .................................... 103 6.2 新板bringup ........................................................ 118 6.3 更改调试串口: .................................................. 127 6.4 uSDHC设备定制(eMMC flash,SDcard, SDIOcard) 133 6.5 LVDS LCD 驱动定制 .......................................... 142 6.6 GPIO_Key 驱动定制 .......................................... 145 6.7 GPIO_LED 驱动定制 ......................................... 149 6.8 Fuse nvram驱动 ................................................. 152 6.9 SPI与SPI Slave驱动 ........................................... 153 6.10 USB 3.0 TypeC 改成 USB 3.0 TypeA(未验证) ... 160 6.11 汽车级以太网驱动定制 ....................................... 160
View full article
Platform: imx8qxp mek b0. OS: android imx-p9.0.0_2.1.0-auto-ga. Hardware block: brief: Android p9 ga enabled the hardware partition, so it is impossible to share dpu between AP and m4, and seamless switching can be achieved by keeping the last m4 ui frame until android ui is ready. To achieve seamless switch between android A core and M4 core on android ga, user needs to modify two parts: Linux kernel: remove init or configure codes of dpu units and lvds used by m4 core M4 code: modify dpu pipes, share memory with android partition.        Switching flow:        M4 release and move camera, dpu to android partition and share the display buffer memory with android, android will not init the dpu subsyses that have been inited by m4 and will keep the m4 last frame ui until android ui is ready. Imx8qxp dpu block: Android and M4 shared dpu path:
View full article
iMX8QXP/iMX8QM have hardware JPEG decoder: The JPEG-D-X core. This is the example code to use this hw decoder in M4 SDK to decode JPEG files. M4_JPEG_DECODER_SDK_2.5.1.7z The attached "rear_view_camera_jpegdec.tar.bz2" is the updated source code for "SDK\boards\mekmimx8qx\demo_apps\rear_view_camera". It is based on SDK 2.5.1 for iMX8QXP MEK. The "rear_view_camera_jpegdec.patch" is the modified code, it hasn't included the added "fsl_jpeg_dec.c" and "fsl_jpeg_dec.h".   The testing used two 256*256 JPEG files, they are RGB color space. We used followed commands to build them into flash.bin: ./mkimage_imx8 -soc QX -rev B0 -append ahab-container.img -c -scfw scfw_tcm.bin -m4 m4_rear_view_camera.bin 0 0x34FE0000 --data demo_rgb.jpg 0x84000000 --data demo_rgb2.jpg 0x84008000 -out flash.bin   If customer need change the JPEG resoluion, they can change them in file "fsl_jpeg_dec.h", APP_JPEG_SIZE_OF_KB is the JPEG file length in memory, aligned in KB.   #define APP_JPEG_WIDTH (256) #define APP_JPEG_HEIGHT (256) #define APP_JPEG_SIZE_OF_KB (32) #define APP_JPEG_FORMAT JPEG_RGB #define APP_JPEG_BUFFER (0x84000000)   To created RGB format JPEG file from RGB data, the customer can use linux unit test application "/unit_tests/JPEG/encoder_test.out". M4_JPEG_DECODER_WINDOW_MODE_SDK_2.5.1.7z Based on JEPG decoder, added DPU CSC support and render JEPG decoded video in overlay window. The architecture is followed: NXP logo is put in FetchLayer0 with RGB565 format, after LayerBlend0, it will be the prim layer for LayberBlend1 (FetchLayer0 can't be used as prim layer for LayerBlend), the JPEG decoder output is put to FetchDecoder0. RGB888 format, and it will be resize to 640*480, and put to x=100, y=100 of the display. (Only the sec layer of LayerBlend can be window mode). Some limitation for layer selection in LayerBlend:
View full article
The Guide is how to use Ubuntu filesystem with i.MX8 series platform.At present, I had try it on i.MX8QXP with 4.14.98 kernel with ubuntu16.04. The Document will be continuously updated with enable VPU, ubuntu18.04. The desktop we can chose Gnome or weston.  Because driver  support issue, gc7000 series gpu not support render Gnome destop but it can render weston destop.  Update 2019/7/31: Ubuntu-i.MX8-weston.pdf   Feature: weston + ubuntu18.04 + 4.14.98 kernel VPU (enable with gplay or gst-play)  GPU (could render desktop and run GPU demo under root privileges on Weston Desktop) I also try ubuntu with gnome desktop, ubuntu18.04 can not run gnome, need use ubuntu19.04. But Gnome Desktop just render by CPU.  ------------------------------------------------------------------------------------- Update 2020/3/6: Ubuntu-i.MX8M.pdf Just a simple guide for IMX8M series, will be  continuously updated. 
View full article
In this doc will show how to adjust display brightness/contrast/saturation by using i.MX8  Display Controller (DC) Subsystem.   HW: i.MX8QXP MEK board SW: Linux 4.14.98_2.0.0 BSP release.   See i.MX 8DualXPlus/8QuadXPlus Applications Processor Reference Manual, Rev. 😧 This kind Matrix total number is 5 , that is 0/1/4/5/9. In this doc using Matrix0 to adjust whole display brightness/contrast/saturation. Matrix0 unit position is located between FramGen unit and Tcon unit, that means using Matrix0 will impact on the whole display contents. Note, this Matrix is applied on RGB color space.    The Matrix is consist of two parts: and  You can program any value into register of A11 to A44 and C1 to C4, Matrix will applied on input RGB data, then output RGB data will changed as you want. In this way, we can change the display brightness/contrast/saturation. The Matrix entry from A11 to A44, their register format is same as below: Each register entry of A11 to A44 , total 13 bit, bit 12 is symbol bit , bit 11 and bit 10 is integer bit, bit 9 to bit 0 is floating point bit. The Matrix entry from C1 to C4, their format is same as below: Each register entry of C1 to C4, total 13 bit, bit 12 is symbol bit, others are integer bit. Now let us choose the matrix that will be used for adjust brightness/contrast/saturation. See this link  https://docs.rainmeter.net/tips/colormatrix-guide/ So we can set matrix as below to change brightness/contrast/saturation   A11=c(sr+s)   A12=c(sg)    A13=c(sb)   A21=c(sb)     A22=c(sg+s)  A23=c(sb)   A31=c(sr)     A32=c(sg)    A33=c(sb+s)   C1=C2=C3=t+b   b as brightness , range[-1.0, 1.0], zero means no change , >0 will increases brightness, <0 will reduce brightness. c as contrast, range [0,2.0) , default is 1.0 , >1.0 is increase , <1.0 is reduce. s is saturation, range [0,1.0], default is 1.0.  Other matrix entry is related to alpha, in this doc not change it, just keep them as zero.     Note here sr,sb,sg value will depend on lumR/ lumG/ lumB constant value you choose, this value may depend on different color standard.   Due to each matrix value is floating point number, and in this doc , i.MX8X run Linux OS. So you can choose do floating point operation in user space program, then pass related register value into kernel space , let driver write them into register. But in this doc, to make Linux kernel driver more simple, I will convert floating point operation into integer operation , then user space app just pass brightness/contrast/saturation value into kernel space, then kernel driver to do left operation in kernel space. So 1024*c and 1024*s is integer number that user space app will passed into kernel space. And in kernel space could be do left integer number operation, then write register value. The kernel patch 8qxp_4.14.98_brightness_contrast_saturation.diff could be used on 4.14.98_2.0.0 BSP release. Test usage, need used one patch that for proptest which from libdrm test case, see 8qxp_prop_test.diff, recompile the proptest case. root@imx8qxpmek:~# ./proptest     //list current drm property CRTC 32         42 bringhtness:                 flags: range                 values: 0 131071                 value:0x0         43 contrast:                 flags: range                 values: 0 2048                 value:0x400         44 saturation:                 flags: range                 values: 0 1024                 value:0x400         45 update:                 flags: range                 values: 0 1                 value:0x0   I add four drm property , brightness, contrast, saturation, update. The “update property” should be set as 1 at last, otherwise kernel space will not update related property. Reference API usage ( in 8qxp_prop_test.diff) +     drmModeObjectSetProperty(fd_rend, obj_id, obj_type, 42, b_int); +     drmModeObjectSetProperty(fd_rend, obj_id, obj_type, 43, c_int); +     drmModeObjectSetProperty(fd_rend, obj_id, obj_type, 44, s_int); +     drmModeObjectSetProperty(fd_rend, obj_id, obj_type, 45, 1);      //run cmd as below , will ask you input related brightness/contrast/saturation value , then will get result in display root@imx8qxpmek:~# ./proptest 32 crtc 45 1   input brightness [-1,1] 0.3 input contrast, >1.0 or <1.0 1.2 input saturation, [0,1] 0.3 brightness 0.300000  0x133 from [-1,1] percent contrast  1.200000  0x4cc >1.0 or <1.0 saturation 0.300000 0x133  from 0.0 to 1.0   Known Issue: For demo this feature , I need run proptest and weston at same time. Due to the set property drm ioctl default allowed by DRM master and DRM control client. But 4.14. kernel, removed the DRM control device node, so I changed to open drm render node fd, and allow DRM render client to using set property drm ioctl.  This is just a workaround, you may not use it. Reference: 1.https://www.nxp.com/docs/en/reference-manual/IMX8DQXPRM.pdf  2.https://docs.rainmeter.net/tips/colormatrix-guide/
View full article
Instrumenting A Board To instrument a board, the connection between the power supply and the target device needs to be broken, usually via a series resistor that's placed on the board. Sometimes the inductor needs to be lifted if no series resistor was included on the rail by the board's designer. In the ideal case, through-hole connections were also provided on the board for the connection of these off-board sensors. Here are three close-up photos that show several boards that have been instrumented: In all three cases, the sensors stand in place via the two outer current carrying wires. The middle and right used insulated wires where as the one on the left used bare wires. In all three cases, the sensor's + connection needs to go towards the power supply and the - connection goes to the target device. The outer wires here are 24-26 gauge. (The relatively heavy gauge wire is used to keep the series resistance of inserting a smart sensor to a minimum.) The ground connection is the middle hole of the smart sensor. In the left and middle photos, a 30 gauge wire connects to the middle hole ground connection on the  board. In the right photo, the ground wire was more conveniently added to a big cap just below the bottom of edge of the photo. Here are wider angle view photos of two of the boards above: The sensors on the left are free-standing since the current carrying wires are stiff enough to hold them upright. Care must be taken since too much flexing will cause a wire to break. Too much bending can also cause a short to the board (and that's why insulated wires were used on these boards). The board on the right has the sensors laying parallel to the board. They are not affixed to the board, but a wire is wrapped around the bundle of ribbon cables out of view past the right edge of the photo. For boards without the through hole connections, the smart sensors need to be immobilized to keep from pulling the SMT pads off the board. If there is room on the board or sides of connectors or large components, the sensors may be attached down with foam double-sticky tape (see photo below, sensor affixed on top i.MX7ULP): For boards where there are no convenient unpopulated areas or there are too many sensors, some other means needs to be devised to immoblize the smart sensors. In the left photo below, two inductors per sensor have been flipped and the two sensors inserted to instrument the two rails. The solder pads on the inductors would easily be broken off by any movement of the smart sensors, so a cage with clamps to hold the ribbon cables was 3D printed. On the back side, there is room for the aggregator to be zip tied to the bottom plate, so the instrumented board can be moved as a single unit with minimal flexing of the ribbon cables.
View full article
UPDATE: Note that this document describes eIQ Machine Learning Software for the NXP L4.14 BSP release. Beginning with the L4.19 BSP, eIQ Software is pre-integrated in the BSP release and this document is no longer necessary or being maintained. For more information on eIQ Software in these releases (L4.19, L5.4, etc), please refer to the "NXP eIQ Machine Learning" chapter in the Linux User Guide for that specific release.  Original Post: eIQ Machine Learning Software for iMX Linux 4.14.y kernel series is available now. The NXP eIQ™ Machine Learning Software Development Environment enables the use of ML algorithms on NXP MCUs, i.MX RT crossover processors, and i.MX family SoCs. eIQ software includes inference engines, neural network compilers, and optimized libraries and leverages open source technologies. eIQ is fully integrated into our MCUXpresso SDK and Yocto development environments, allowing you to develop complete system-level applications with ease. Source download, build and installation Please refer to document NXP eIQ(TM) Machine Learning Enablement (UM11226.pdf) for detailed instructions on how to download, build and install eIQ software on your platform. Sample applications To help get you started right away we've posted numerous howtos and sample applications right here in the community. Please refer to eIQ Sample Apps - Overview. Supported platforms eIQ Machine learning software for i.MX Linux 4.14.y supports the L4.14.78-1.0.0 and L4.14.98-2.0.0 GA releases running on i.MX 8 Series Applications Processors. For more information on artificial intelligence, machine learning and eIQ Software please visit AI & Machine Learning | NXP.
View full article
In new iMX8QM and iMX8QXP BSP, it had implemented hardware partition to split the resource and memory regions. The default Android Auto BSP had given example for shared memory between M4 and A core, it is used for RPMSG. Here is an example to add a new shared memory for iMX8QXP MEK board with Android Auto P9.0.0_GA2.1.0 BSP, which can be accessed in both M4, Uboot and Linux Kernel. The new shared memory region is from 0xF6000000 to 0xFDFFFFFF, total 128MB, it covers the RPMSG region too. RPMSG shared memory is moved to 0xF6000000 ~ 0xF6BFFFFF, total 12MB. vendor_nxp_fsl-proprietary_uboot-firmware.patch SCFW patch for board file to change the old shared memory region (0x90000000~0x90BFFFFF) to new shared memory region (0xF6000000~0xFDFFFFFF). This patch is applied to android_build/vendor/nxp/fsl-proprietary/uboot-firmware/imx8q_car/board-imx8qxp.c, after patched, copy this file to SCFW porting kit and build out a new SCFW image, put it to "android_build/vendor/nxp/fsl-proprietary/uboot-firmware/imx8q_car/mx8qx-scfw-tcm.bin". vendor_nxp-opensource_uboot-imx.patch This is the Uboot patch to map the shared memory region, if Uboot doesn't need access these memory, this patch is not needed. vendor_nxp-opensource_kernel_imx.patch This is the kernel patch to map the shared memory region. Note: VPU reserved memory address shouldn't be changed, otherwise it will impact the VPU function. So the new reserved memory region had been moved to 0xF600000~0xFDFFFFFF. vendor_nxp_mcu-sdk-auto_SDK_MEK-MIMX8QX.patch M4 patch for RPMSG address changed from 0x90000000 to 0xF6000000. Note: 1. In this example, we put the two shared memory regions together, then it will not split the memory region used in Linux. Another reason for such modification is the limitation of memory region counts in SCFW. 2. Since the RPMSG shared memory had been moved from 0x90000000 to 0xF6000000, the M4 code who used shared memory should also be changed. 2019-07-29 Update: When "#define PHYS_SDRAM_2_SIZE  0x0" in Uboot, it will create a 0 size memory region, this will impact the Uboot shared memory patch. Added the "uboot_imx8_cpu.patch" to avoid such issue.
View full article
Introduction This document describes the Spread Spectrum support for displays on i.MX 8QuadMax and i.MX 8QuadXPlus, specific for LVDS display. It describes the underlying HW function, how to enable it and the intended capability. The display controller (DC) subsystem on i.MX 8QuadMax and i.MX 8QuadXPlus uses an AVPLL to generate the reference clock for operation of the LVDS PHYs.  Enabling Spread Spectrum on the reference clock will result in the PHY interfaces being spread as well. This Spread Spectrum feature is controlled by the SCU firmware and can be enabled or disabled by configuring the board file of the SCU firmware porting kit. (The Spread Spectrum feature is added starting from SCFW porting kit V1.2.2 release which can be download from NXP web site “i.MX Software and Development Tool”.) The User Guide will include following content: 1. Introduction ............................................................................ 1 2. Configuration of the frequency modulation ......................... 2 3. Support in SCFW Porting Kit ............................................... 4 4. Modulation Characteristics ................................................... 4 5. Enablement Example ............................................................. 5 6. Revision History .................................................................... 7 For more information, please check the attachment "User Guide of Spread Spectrum for i.MX8QM_QXP Display.pdf".   Rev2.0 Update For SCFW Porting Kit V1.2.5 and later version, please check document "User Guide of Spread Spectrum for i.MX8QM_QXP Display 2.0.pdf" with updated algorithm. Rev2.1 Update For SCFW Porting Kit V1.2.10 and later version, please check document "User Guide of Spread Spectrum for i.MX8QM_QXP Display 2.1.pdf" with fspread value selection feature. Users can choose the percentage of frequency spread from following values: 0%, 0.4%, 1.0%, 1.4%, 2.0%.
View full article