For most of interlace output camera sensors, they only support up to 30fps sample rate. In this case, we may not get good display quality. In order to improve the permance under this case, we can use IPU VDI function to increase the output frequency to be 60fps and then we can get a better quality. The patch is an example to support YUV422(YUYV) 60fps VDI for Android camera preview. SW Platform: kk4.4.2_1.0.0-ga HW Platform: imx6q-sabresd Features: Support YUV422(YUYV) input format; Support IPU 60fps VDI; Supprot 60fps camera preview, but don't support camera capture. Patch: The linux kernel patch to support additonal IPU function can be found at: https://community.freescale.com/docs/DOC-173003 The Android Camera HAL can be found at here. Note: 1. The g_vdi_double is used to decide whether to support these features. When g_vdi_double is set to be 1, these features will be enabled; Or these features will be disabled and camera feature will be the same with default release. 2. The patch should be used at hardware\imx\mx6\libcamera2. 3. Accoeding to the real user case, the user can set IPU VDI motion mode to be 0 or 1 , but NEVER to be 2. 4. The fps can be up to 60fps, but it is not stable now.

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/

    In i.MX93 EVK, it use RGMII in ethernet connection. Some customer use RMII connection. This article describe RMII HW design and SW config.  It listed four cases in attached.  

The i.MX 8QXP MEK does not allow the OV5640/LVDS/LCD usage only by changing the device tree anymore. It occurs because the M4 owns the i2c resources, so the A core must use rpmsg to enable virtual drivers. Due to this, if the user changes the device tree, for instance, the *ov5640.dtb, the kernel won't boot, entering in the following loop: [    8.603353] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).      [    8.610025] [drm] No driver support for vblank timestamp query.              [    8.616077] imx-drm display-subsystem: bound imx-drm-dpu-bliteng.2 (ops dpu_) [    8.624978] imx-drm display-subsystem: bound imx-dpu-crtc.0 (ops dpu_crtc_op) [    8.632526] imx-drm display-subsystem: bound imx-dpu-crtc.1 (ops dpu_crtc_op) [    8.639833] imx-drm display-subsystem: failed to bind ldb@562210e0 (ops imx_7 [    8.648428] imx-drm display-subsystem: master bind failed: -517 With the approach provided in this post, it is possible to make this change manually, only by changing the flash.bin at U-boot for a non-m4 one. In order to make the changes to the flash.bin file, it’s needed to obtain the following files: - u-boot.bin from internal u-boot provided by NXP. - scfw_tcm.bin from SCFW porting kit - bl31.bin from ARM Trusted Firmware - SECO firmware container image Disclaimer The described procedures in this document target a GNU/Linux (Ubuntu 20.04 LTS) and it’s focused on iMX8QXP B0 + BSP L4.19.35_1.1.0. Required packages 1 - Install ARM64 ToolChain: 1.1 - Install ARM64 GCC and G++ cross-compilers: # apt install gcc-aarch64-linux-gnu g++-aarch64-linux-gnu 2 - Install ARM32 GCC6 ToolChain: 2.1 - Download the ARM32 6 Toolchain and install it: $ mkdir ~/gcc_toolchain $ cp ~/Downloads/gcc-arm-none-eabi-6-2017-q2-update-linux.tar.bz2 ~/gcc_toolchain/ $ cd ~/gcc_toolchain/ $ tar xvjf gcc-arm-none-eabi-6-2017-q2-update-linux.tar.bz2 # apt-get update # apt-get install srecord 3 - Download MKimage 3.1 - Create a new directory desired to the packages: $ mkdir flash_build $ cp flash_build 3.1 - Clone the MKimage: $ git clone https://source.codeaurora.org/external/imx/imx-mkimage -b imx_4.19.35_1.1.0 4 - U-boot build 4.1 - Clone the U-boot  $ git clone https://source.codeaurora.org/external/imx/uboot-imx -b imx_v2019.04_4.19.35_1.1.0 $ cd uboot-imx 4.2 - Export the ARM64 ToolChain:  $ export ARCH=arm64 $ export CROSS_COMPILE=/usr/bin/aarch64-linux-gnu- 4.3 - Build it:  $ unset LDFLAGS $ make -j4 imx8qxp_mek_defconfig $ make 4.4 - Copy the binary files to the MKimage/iMX8QX directory:  $ cp spl/u-boot-spl.bin ../imx-mkimage/iMX8QX/ $ cp u-boot-nodtb.bin ../imx-mkimage/iMX8QX/ $ cd ..   5 - ARM Trusted Firmware 5.1 - Clone the imx-atf:  $ git clone https://source.codeaurora.org/external/imx/imx-atf -b imx_4.19.35_1.1.0 $ cd imx-atf 5.2 - Build it:  $ unset LDFLAGS $ make PLAT=imx8qx bl31 5.3 - Copy the binary files to the MKimage/iMX8QX directory:  $ cp build/imx8qx/release/bl31.bin ../imx-mkimage/iMX8QX/ $ cd ..   6 - SCFW 6.1 - Export the ARM32 GCC6 Toolchain:  $ export TOOLS=~/gcc_toolchain/ 6.2 - Download the BSP L4.19.35_1.1.0_SCFW and copy it to the flash_build directory:  $ cp ~/Downloads/imx-scfw-porting-kit-1.2.7.1.tar.gz $ tar xvzf imx-scfw-porting-kit-1.2.7.1.tar.gz $ cd packages/ $ chmod a+x imx-scfw-porting-kit-1.2.7.1.tar.gz $ ./imx-scfw-porting-kit-1.2.7.1.bin 6.3 - Build it to i.MX 8QXP MEK B0:  $ cd imx-scfw-porting-kit-1.2.7.1/src/ $ tar xvzf scfw_export_mx8qx_b0.tar.gz $ cd scfw_export_mx8qx_b0/ $ make qx R=B0 B=mek 6.4 - Copy the binary file to the MKimage/iMX8QX directory:  $ cp build_mx8qx_b0/scfw_tcm.bin ../../../../imx-mkimage/iMX8QX/ $ cp ../../../../ 7 - SECO Firmware Container Image 7.1 - Download the SECO firmware binaries and copy it to the flash_build directory $ cp ~/Downloads/firmware-imx-7.9.bin . $ chmod a+x firmware-imx-7.9.bin 7.2 - Copy the binary files to the MKimage/iMX8QX directory:  $ cp firmware-imx-7.9/firmware/seco/mx8qx-ahab-container.img /imx-mkimage/iMX8QX/ 8 - Build flash.bin 8.1 - In a new terminal, open the imx-mkimage directory: $ cd flash_build/imx-mkimage 8.2 - Build it:  $ make SOC=iMX8QX flash 8.3 - Deploy it to the SDCard:  $ sudo dd if=iMX8QX/flash.bin of=/dev/sdX bs=1k seek=32 && sync Now, you are able to use any non-rpmsg.dtb without kernel errors. Author: Pedro Jardim: [email protected]

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 MMDC initialization. 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 validation boards.

INTRODUCTION REQUIREMENTS HARDWARE CONNECTIONS IMPLEMENTATION AND TESTING 1. INTRODUCTION This document explains how to generate and compile a custom Linux application on the UDOO NEO board  for using the GPIO headers to connect a 16x2 LCD. 2. REQUIREMENTS First of all, the Linux image used is UDOObuntu 2 RC1 (Ubuntu 14.04), available for download from the following link:      Downloads - UDOO​ For creating a bootable SD card and other basic setup please refer to the following guidelines:      Very First Start Then, it is required to install the proper drivers to ensure connectivity, including USB communication with Linux terminal of the target board. Please refer to the link below:      Usb Direct Connection The LCD driver of this document was already implemented on a previous application, and could be found on the following document: Customizing MQX applications on i.MX6SX. 3. HARDWARE CONNECTIONS Now, the hardware connection considers a 4-bit interface to the LCD plus the Register Select (RS) and Enable (E) pins, so, six GPIO are used. For this example, digital input/output pins are used as shown on the following figure (purple rectangle): Where: NEO GPIO GPIO148 GPIO105 GPIO149 GPIO140 GPIO141 GPIO142 LCD pin E RS DB7 DB6 DB5 DB4 4. IMPLEMENTATION AND TESTING After booting Linux, a text editor like nano should be used to generate the program. The three main configurations for GPIOS are the following (using the E pin as example): Export the GPIO. echo 148 > /sys/class/gpio/export Configure the direction of the GPIO (as output). echo out > /sys/class/gpio/gpio148/direction Set the GPIO value to Low or High: echo 0 > /sys/class/gpio/gpio148/value echo 1 > /sys/class/gpio/gpio148/value So, based on these configurations and the LCD driver already implemented on the document mentioned on Requirements section, the complete C application for Linux could be generated (find it attached). The GCC compiler already included on the UDOObuntu image could be used to generate the executable application. The picture below shows the terminal of the UDOO NEO board including the text editor, compilation and execution commands of the application. The used commands are the following: $ nano lcd16x2_imx6sx.c $ sudo gcc lcd16x2_imx6sx.c -o lcd $ sudo ./lcd Finally, the following image shows the LCD with the application working on the UDOO NEO board, connecting the LCD using a proto shield: NOTE: Ensure that M4 core is not running or using the same pins, in order to avoid unexpected behavior on GPIOs.

The i.MX 6 D/Q L3.035_1.1.3 patch release is now available on the www.freescale.com ·         Files available # Name Description 1 L3.0.35_1.1.3_TEMP_PATCH This patch release is based on the i.MX 6Dual/6Quad Linux   L3.0.35_1.1.0 release. The purpose of this patch release is fix the   miscalibration issue for the thermal sensor.

When you do long test (days or weeks) test on i.MX board and your test fails, you often wants to know what has happen with a JTAG probe. The problem is when you have 50 boards running in parallel, you don't have the budget to have 50 JTAG debug probe. If you do a "hot plug" of your JTAG probe, you have roughly one chance out 2 to reset your board... so you'll have to wait another couple of hour to resee the problem. Anyway to have a reliable JTAG plug with no reset, it is really simple... cut the RESET line on your cable! then you'll still be able to "attach" to your i.MX. On the MEK board, with a 10-pin JTAG connector, you have the cut the cable line 10 of the ribbon cable: On the cable, cut the reset line like this: With my Lauterbach JTAG  probe, when I do a "hot plug" I never have a reset of my i.MX. BR Vincent

OpenCV (Open Source Computer Vision Library) is released under a BSD license and hence it’s free for both academic and commercial use. It has C++, C, Python and Java interfaces and supports Windows, Linux, Mac OS, iOS and Android. OpenCV was designed for computational efficiency and with a strong focus on real-time applications. Written in optimized C/C++, the library can take advantage of multi-core processing. Enabled with OpenCL, it can take advantage of the hardware acceleration of the underlying heterogeneous compute platform In current bsp , which supports opencv 2.4, but some customer wants to use the opencv 3.1, then one can use the morty yocto bsp to install the opencv. step 1: for how to install the package on ubuntu and how to build the environment, pls refer to the bsp user guide, for how to build the branch morty, try to use the command as below: MACHINE=imx6qsabresd source fsl-setup-release.sh -b build_qt5 -e fb step 2: for how to enable the opencv, pls add the command as below in the local.conf, the path is fsl-release-bsp/build/conf, "CORE_IMAGE_EXTRA_INSTALL += "libopencv-core-dev libopencv-highgui-dev libopencv-imgproc-dev libopencv-objdetect-dev libopencv-ml-dev" CORE_IMAGE_EXTRA_INSTALL += "opencv-apps opencv-dev python-opencv python-modules"" then build again by bitbake. then you can find the image in the fsl-release-bsp/build/tmp/deploy/images/im6qsabresd/, one can find the opencv libary when extracting the rootfs file step 3: then you can use dd command or mfgtool downloading the image file to the board and use the opencv libary file. other usage: one can install the populate_sdk to build the source code, for opencv 3.1, maybe you will find some g++ issue to fix, so just simple introduce this use the command: bitbake -c populate_sdk fsl-image-gui(for example)  then you can find the sdk install file in the fsl-release-bsp/build_x11/tmp/deploy/sdk, run the install file, set the installation file in the /opt/poky, then you can find the toolchain in the /opt/poky after install successfully.

Software Update and Recovery The information reproduced above is from Android User Guide R10.2, found into Android release package. It is possible to format the /data and /cache partitions or update software based on a update script using recovery mode as follows: Prepare for all Android source code that assumed to be saved in ~/myandroid directory. Prepare for ADB over USB. make sure that ADB over USB is ok. USB cable is connected. Refer to i.MX51 Android ADB over USB section for more information. Connect the UART to the PC and open a terminal to check for printed messages Enter the recovery by manual for imx51_BBG board:       setenv bootargs_android_recovery 'setenv bootargs ${bootargs} init=/init root=/dev/mmcblk0p4 rootfs=ext4 di1_primary'       setenv bootcmd_android_recovery 'run bootargs_base bootargs_android_recovery;mmc read 0 ${loadaddr} 0x800 0x2000;bootm'       run bootcmd_android_recovery For imx53_SMD board:       setenv bootargs_android_recovery 'setenv bootargs ${bootargs} init=/init root=/dev/mmcblk0p4 rootfs=ext4'       setenv bootcmd_android_recovery 'run bootargs_base bootargs_android_recovery;mmc read 0 ${loadaddr} 0x800 0x2000;bootm'       run bootcmd_android_recovery When system has completed bootup,  You will see this screen: You can press "MENU" "HOME" or "F1" (by USB keyboard, for developer)" going to the text menu like this: Select the required option using the direction keys on the keypad or keyboard. Apply sdcard:update.zip, you may update the software from update.zip as shown in the following example: Copy this directory from android source code myandroid/bootable/recovery/etc to a tempepory directory, such as ~/recovery. cd ~/recovery and remove init.rc from this directory. Edit ./META-INF/com/google/android/updater-script according to the required commands. for example, in order to format /system partition and use update.zip to update system partition, copy whole the entire content directory to system partition, all commands are found in ~/myandroid/bootable/recovery/update/install.c You must notice, when your signing the zip package, it will lose ALL of the permission information, you need to set the right permission in the script. You can find the example in ./META-INF/com/google/android/updater-script Copy update-binary, Copy out/target/product/YOU_PRODUCT/system/bin/updater to ~/recovery/META-INF/com/google/android/update-binary Create a directory called system and copy some files you would like to update to ./system. Create a directory called res to save the public key of your system.         fsl@fsl-desktop:~/recovery$ mkdir res         fsl@fsl-desktop:~/recovery$ ~/myandroid/out/host/linux-x86/framework/dumpkey.jar ~/myandroid/build/target/product/security/testkey.x509.pem > res/keys Create a package called recovery.zip using the zip command         fsl@fsl-desktop:~/recovery$zip recovery.zip -r ./META-INF ./system ./res recovery.zip is located in the current directory. Then create a digital signature for recovery.zip package as follows.         fsl@fsl-desktop:~/recovery$ cd ~/myandroid         fsl@fsl-desktop:~/myandroid$ make signapk         fsl@fsl-desktop:~/myandroid$ cd ~/recovery         fsl@fsl-desktop:~/recovery$ java -jar ~/myandroid/out/host/linux-x86/framework/signapk.jar -w ~/myandroid/build/target/product/security/testkey.x509.pem ~/myandroid/build/target/product/security/testkey.pk8 recovery.zip recovery_signed.zip recovery_signed.zip is located in the current directory. Copy it to the SD card using ADB         fsl@fsl-desktop:~/recovery$ adb push recovery_signed.zip /sdcard/update.zip update.zip is completed and the system is updated based on the commands in the update-script. Check for error messages on the LCD. Wipe data/factory reset. /data and /cache partitions are formatted. Wipe cache partition. /cache partition is formatted. Reboot the system.

The Gui-guilder doesn't provide remote debug function in IDE and we still need use Yocto to build project or copy binary to board rootfs. This knowledge base will provide a solution about how to use VSCode to remote debug LVGL project on i.MX93 EVK board.    Yocto toolchain: L6.6.x GUI GUILDER: v1.8.0   Need to open GUI GUILDER project in VSCode.   1.Scripts in VScode   1.1 build.sh Modify build.sh in <LVGL project>/ports/linux     #!/bin/sh toolchain=$1 if [ -z "$toolchain" ];then toolchain=/opt/fsl-imx-xwayland/6.1-mickledore/sysroots/x86_64-pokysdk-linux/usr/share/cmake/armv8a-poky-linux-toolchain.cmake if [ ! -r $toolchain ];then toolchain=/opt/fsl-imx-xwayland/6.1-langdale/sysroots/x86_64-pokysdk-linux/usr/share/cmake/armv8a-poky-linux-toolchain.cmake fi fi toolchain_path=$(echo $toolchain |sed -E 's,^(.*)/sysroots/.*,\1,') toolchain_arch=armv8a-poky-linux if [ ! -r $toolchain -o ! -r "$toolchain_path/environment-setup-$toolchain_arch" ];then echo "ERROR: Yocto Toolchain not installed?" exit 1 fi if [ -n "$BASH_SOURCE" ]; then ROOTDIR="`readlink -f $BASH_SOURCE | xargs dirname`" elif [ -n "$ZSH_NAME" ]; then ROOTDIR="`readlink -f $0 | xargs dirname`" else ROOTDIR="`readlink -f $PWD | xargs dirname`" fi BUILDDIR=$ROOTDIR/../build rm -fr $BUILDDIR mkdir $BUILDDIR . "$toolchain_path/environment-setup-$toolchain_arch" echo "start build..." cd $ROOTDIR/linux/lv_drivers/wayland/ cmake . make cd $BUILDDIR toolchain_path=/opt/fsl-imx-wayland/6.6-scarthgap/sysroots/x86_64-pokysdk-linux/usr/share/cmake/armv8a-poky-linux-toolchain.cmake cmake -G 'Ninja' .. -DCMAKE_TOOLCHAIN_FILE=$toolchain_path -Wno-dev -DLV_CONF_BUILD_DISABLE_EXAMPLES=1 -DLV_CONF_BUILD_DISABLE_DEMOS=1 -DCMAKE_CXX_FLAGS="-ggd3 -O0" -DCMAKE_BUILD_TYPE=Debug ninja if [ -e gui_guider ];then echo "Binary locates at $(readlink -f gui_guider)" ls -lh gui_guider fi # Copy binary to board scp $BUILDDIR/gui_guider [email protected]:/opt     1.2 tasks.json     { "version": "2.0.0", "tasks": [ { "label": "Build", "type": "shell", "command": "./build.sh /opt/fsl-imx-wayland/6.6-scarthgap", "options": { "cwd": "${workspaceFolder}/ports/linux" }, "problemMatcher": [ "$gcc" ], } ] }       1.3 launch.json   miDebuggerServerAddress is board ip address.     { "version": "0.2.0", "configurations": [ { "name": "(gdb) Launch", "preLaunchTask": "Build", "type": "cppdbg", "request": "launch", "program": "${workspaceFolder}/build/gui_guider", "args": [], "stopAtEntry": false, "cwd": "${workspaceFolder}/", "environment": [], "externalConsole": false, "MIMode": "gdb", "logging": { "engineLogging": true, "trace": true, "traceResponse": true }, "debugStdLib":true, "miDebuggerPath":"/usr/bin/gdb-multiarch", //DO NOT USE GDB IN SDK!!!! "miDebuggerServerAddress": "192.168.31.243:12345", "setupCommands": [ { "description": "Enable pretty-printing for gdb", "text": "-enable-pretty-printing", "ignoreFailures": true, "text": "set remotetimeout 100", } ] }] }       2. Launch gdbserver on board     export SHELL=/opt/gui_guider gdbserver 192.168.31.243:12345 /opt/gui_guider       3. Debug in VSCode   Click (gdb)launch, the source code will be compiled. Then you will see the breakpoint in program. Enjoy your debug~    

Display on LVDS0 or LVDS1 is normal, but some customer need  larger screen and they need the dual LVDS work on the same time. In another word, it is to use the dual 8 connection. Here I give the simple introduction on this. Environment Board: MCIMX6Q-SDP (Or the board customer design) BSP:  Linux or Android BSP provided by Freescale Screen: M190PW01-V8 19(Take this as example) Steps: 1\ Hardware connection Make sure the hardware connection is right. The 4 pairs of difference signals on both LVDS0 and LVDS1 work, but in our reference board MCIMX6Q-SDP only 3 pairs of difference signals work. To make this screen working well the connection must be proper connect. Take the screen M190PW01-V8 19 as a example, the connection is as follow: 2\ Software modify Here we can know the screen works on the RGB24 mode not the RGB666, as the connection is already right. So the next step is to modify the code. As customers use differently screens, they have to porting the screen driver first.  About porting customers need to modify the  ldb.c  according to the datasheet of the screen in BSP. The parameters and timing should be set right.  Also the board.c need to be modified, RGB24 mode should also be set. About the porting Lvds screen steps, details you can refer to the Porting LVDS LCD With Low Resolution to i.MX6  in our community. 3\ Command special in u-boot After porting success the LVDS  and build the BSP. The run the images built on the board then boot up the board. In the u-boot the command should be set, about the display section is : video=mxcfb0:dev=ldb,LDB-1080P60,if=RGB24 ldb=spl0. The default BSP provided by Freescale is support dual LVDS display, but the display mode should be right so it can work well. Hope this can give some help to you.

This sharing introduces how to porting the deepseek to the #i.MX8MP i.MX93EVK  with the Yocto BSP by llama.cpp The main test model used in this document is the Qwen model that is distilled and quantized based on the deepseek model. For other versions of the deepseek model, you can refer to the steps in the document to download different models for testing. 1. Set up the demo ON PC a. Prepare the cross-compiling. See the i.MX Yocto Project User's Guide for detailed information how to generate Yocto SDK environment for cross-compiling. Get the User's Guide. To activate this Yocto SDK environment on your host machine, use this command:   :$ source <Yocto_SDK_install_folder>/environment-setup-cortexa53-crypto-poky-linux   b. Cross-compile the llama.cpp eg: i.MX93   :$ git clone https://github.com/ggerganov/llama.cpp :$ mkdir build_93 :$ cd build_93 :build_93$ cmake .. -DCMAKE_SYSTEM_NAME=Linux -DCMAKE_SYSTEM_PROCESSOR=aarch64 -DCMAKE_C_COMPILER=aarch64-poky-linux-gcc -DCMAKE_CXX_COMPILER=aarch64-poky-linux-g++ :build_93$ make -j8 :build_93$ scp bin/llama-cli root@<your i.MX93 board IP>:~/ :build_93$ scp bin/*.so root@<your i.MX93 board IP>:/usr/lib/   c. Get the DeepSeek model on the huggingface eg: Dowload the DeepSeek-R1-Distill-Qwen-1.5B-Q4_K_M.gguf model Download the required Deepseek model in the huggingface. ON Board a.Test the Deepseek on the i.MX93 board   :~/# ./llama-cli --model DeepSeek-R1-Distill-Qwen-1.5B-Q4_K_M.gguf     b. Results shown below:   2. Results Analysis The effects of different models on different boards were tested. It should be noted that the biggest obstacle limiting the running of the model on the board is memory.The test results including CPU and memory usage are as follows: a. i.MX8mp + DeepSeek-R1-Distill-Qwen-7B-IQ4_XS b. i.MX93 + DeepSeek-R1-Distill-Qwen-1.5B-Q4_K_M   After testing, the speed at which i.MX8MP runs DeepSeek-R1-Distill-Qwen-7B-IQ4_XS to generate tokens is about 1 token per second. The speed at which i.MX93 runs DeepSeek-R1-Distill-Qwen-1.5B-Q4_K_M to generate tokens is about 1.6 token per second.  The above test results for the generation speed are only rough test results and are for reference only. The above icons show the CPU and memory usage of i.MX during the DeepSeek model running. It should be pointed out that the CPU efficiency affects the speed of model token generation. The memory size of the board limits whether the model can run in the corresponding development board. This is a balance between running speed and required memory size. Higher accuracy, such as using a 7B model, will result in a decrease in running speed.

The layer attached to this article is obsolete. Please use the meta-imx-fastboot GitHub repo instead.   The purpose of this article is to show how to reduce the boot time on i.MX 8QXP using U-Boot Falcon Mode. The general technique is presented in the AN14093. This article was tested on LF-6.6.23-2.0.0 BSP. How to do it 1. Follow the steps in the i.MX Yocto Project User's Guide and prepare your Yocto building environment. We will further assume that the BSP is in the ~/imx-yocto-bsp directory and the build directory is ~/imx-yocto-bsp/build. 2. Unpack the attached archive in ~/imx-yocto-bsp/sources. This should create the ~/imx-yocto-bsp/sources/meta-imx-fastboot directory.  3. Add the meta-imx-fastboot layer to your build using the following command: bitbake-layers add-layer ~/imx-yocto-bsp/sources/meta-imx-fastboot 4. If you've previously built an image in the same tree, clean the u-boot-imx and imx-boot packages using the following command: bitbake -c clean u-boot-imx imx-boot 5. Build the new image. Out of the box, this package is configured for core-image-minimal. We will show you below how to adapt it for other images: bitbake core-image-minimal 6. Write the resulted image on eMMC/SD using your preferred method and boot the board. 7. By default, the board will boot normally. To enable fast boot, stop the board in U-Boot, and run the following command: u-boot => run prepare_fdt 8. Reboot the board. From this point on, the board should boot in fast mode. Far less messages will be printed by the kernel or systemd during boot. You may further optimize the boot time by removing unnecessary features from the kernel and/or removing unnecessary services started by systemd. Please refer to AN14093. 9. If you ever want to re-enter U-Boot, please keep the 'c' key pressed in the serial console during board power-on. It's easiest if you press and keep the 'c' key pressed before powering on/pressing the reset button. How it works The layer we've added contains patches for U-Boot, ATF and imx-mkimage. In addition, it modifies the core-image-minimal recipe. In U-Boot, the necessary options for Falcon Mode are added in a new configuration file, named imx8qxp_mek_falcon_defconfig, as well as an implementation of the spl_start_uboot() function. In ATF, the device tree load address is added in the correct parameter. In mkimage, two new targets are created: kernel-atf-container.img (to be deployed in the boot partition) and uImage (to be deployed in the rootfs). The change in the core-image-minimal recipe ensures that the new files are copied in the resulting image. If you want to build a different image, you need to copy the content of core-image-minimal.bbappend in a new file, named according to the image you want to build. For example, if you want to build imx-image-full, you could use the following command: cp ~/imx-yocto-bsp/sources/meta-imx-fastboot/recipes-fsl/images/core-image-minimal.bbappend ~/imx-yocto-bsp/sources/meta-imx-fastboot/recipes-fsl/images/imx-image-full.bbappend       *** DISCLAIMER *** Any support, information, and technology (“Materials”) provided by NXP are provided AS IS, without any warranty express or implied, and NXP disclaims all direct and indirect liability and damages in connection with the Material to the maximum extent permitted by the applicable law. NXP accepts no liability for any assistance with applications or product design. Materials may only be used in connection with NXP products. Any feedback provided to NXP regarding the Materials may be used by NXP without restriction.

Hello everyone! In this quick example its focused on how to customize uboot code to generate an uboot image with a silent console so its speed up the flash and boot time, this may provide helpful for customers who have a bigger images or just want to have a silent console. Note: this should not be enabled if the image is still being under test, since this will disable all communication with the debug terminal and there won't be boot messages. Requirements: I.MX 8M Nano DDR4 EVK i.MX 8M Nano EVK Prebuilt image (6.1.1-1.0.0) UUU tool First clone the code from the uboot repository: $ git clone https://github.com/nxp-imx/uboot-imx -b lf-6.1.1-1.0.0 $ cd uboot-imx After we get the code, then proceed to enable the silent console in the uboot defconfig: $ nano configs/imx8mn_ddr4_evk_defconfig CONFIG_SILENT_CONSOLE=y CONFIG_SILENT_U_BOOT_ONLY=y For this to actually work we need to create the silent environmental variable and give it a value different from "0": $ nano include/configs/imx8mn_evk.h "silent=1\0"      \ As specified in our Linux porting guide: Generate an SDK from the Yocto Project build environment with the following command. To set up the Yocto Project build environment, follow the steps in the i.MX Yocto Project User's Guide (IMXLXYOCTOUG). In the following command, set Target-Machine to the machine you are building for. See Section "Build configurations" in the i.MX Yocto Project User's Guide (IMXLXYOCTOUG) Set up the host terminal window toolchain environment: $ source/opt/fsl-imx-xwayland/6.1.1/environment-setup-aarch64-poky-linux $ export ARCH=arm64 Build uboot binary: $ make distclean $ make imx8mn_ddr4_evk_defconfig $ make Build ARM Trusted Firmware (ATF) $ cd .. $ git clone https://github.com/nxp-imx/imx-atf -b lf-6.1.1-1.0.0 $ cd imx-atf/ $ make PLAT=imx8mn bl31 In case you get the error aarch64-poky-linux-ld.bfd: unrecognized option '-Wl,-O1' $ unset LDFLAGS Download the DDR training & HDMI binaries $ cd .. $ mkdir firmware-imx $ cd firmware-imx $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.19.bin $ chmod a+x firmware-imx-8.19.bin $ ./firmware-imx-8.19.bin Accept EULA and the firmware will be deployed. Download imx-mkimage and build the boot image $ cd .. $ git clone https://github.com/nxp-imx/imx-mkimage -b lf-6.1.1-1.0.0 $ cd imx-mkimage $ cp ../uboot-imx/spl/u-boot-spl.bin iMX8M/ $ cp ../uboot-imx/u-boot-nodtb.bin iMX8M/ $ cp ../uboot-imx/arch/arm/dts/imx8mn-ddr4-evk.dtb iMX8M/ $ cp ../imx-atf/build/imx8mn/release/bl31.bin iMX8M/ $ cp ../firmware-imx/firmware-imx-8.19/firmware/ddr/synopsys/ddr4_* iMX8M/ $ cp ../uboot-imx/tools/mkimage iMX8M/mkimage_uboot $ make SOC=iMX8MN flash_ddr4_evk After this we can download our uboot image to our board, we can either use the uboot image for boot or for flashing purpose only. We can compare the time it takes using UUU with a standard pre-built image uuu -V -b emmc_all imx-boot-imx8mn-ddr4-evk-sd.bin-flash_ddr4_evk imx-image-full-imx8mnevk.wic It takes 485.5 seconds using normal uboot with debug console enabled. uuu -V -b emmc_all flash.bin imx-image-full-imx8mnevk.wic It takes 477.5 seconds using silent uboot console. Even if the speed is not greatly improved (~8 seconds), in larger files it could help to speed up flashing, even if wants to have the console silent is a good option. Hope everyone finds this useful! For any question regarding this document, please create a community thread and tag me if needed. Saludos/Regards, Aldo.

  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/...  

FAQ Question: I receive the following error message when compiling GTK2 using LTIB" Making all in demos make[2]: Entering directory `/home/ltib/rpm/BUILD/gtk+-2.14.3/demos' no --raw --build-list \         apple_red  ./apple-red.png \                 gnome_foot ./gnome-foot.png \         > test-inline-pixbufs.h \ || (rm -f test-inline-pixbufs.h && false) /bin/sh: no: command not found make[2]: *** [test-inline-pixbufs.h] Error 1 make[2]: Leaving directory `/home/ltib/rpm/BUILD/gtk+-2.14.3/demos' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/ltib/rpm/BUILD/gtk+-2.14.3' make: *** [all] Error 2 error: Bad exit status from /home/ltib/tmp/rpm-tmp.69212 (%build) Answer: Some packages on your host are missing, install the following packages: For deb distributions: sudo apt-get install libgtk2.0-dev or For Fedora distributions: sudo yum install gtk2-devel IMPORTANT: After install the package above, be sure to remove the installed GTK package on your ltib: On your LTIB directory: rm -rf rpm/BUILD/gtk+-2.14.3/ Question: I receive the following error message when booting through NFS: "Root-NFS: Server returned error -13 while mounting /tftpboot/ltib" Answer: Probabilty you remake your rootfs and forgot to restart NFS server. To solve this issue the command: "service nfs restart" Question: I am receiving "error: cannot open Name index using db3" when installing LTIB on new Ubuntu 9.10 Answer: Edit the file "ltib" and modify line 2428 to: $cf->{rpm}           = "rpm --force-debian"; Question: I receive the error message "Cannot create lockfile. Sorry." when I try to open minicom. Answer: This error message is generated because your user doesn't have permission to create a lock file in /var/lock. Change /var/lock permission: # chmod 777 /var/lock Question: I receive the error message "cannot open /dev/ttyS0: Permission denied" when I try to open minicom. Answer: This error message is generated because your user doesn't have permission to open /dev/ttyUSB0. Change /dev/ttyUSB0 permission: # chmod 777 /dev/ttyS0 Question: Compilation of e2fsprogs package or others packages with dependencies like Qtopia using LTIB in Debian derived linux system like Ubuntu makes an error like: make[1]: Leaving directory `/home/daiane/LTIB/L2.6.24_1.2.1_SDK_042008/rpm/BUILD/e2fsprogs-1.34/tests/progs' making all in po make[1]: Entering directory `/home/daiane/LTIB/L2.6.24_1.2.1_SDK_042008/rpm/BUILD/e2fsprogs-1.34/po' : --update cs.po e2fsprogs.pot rm -f cs.gmo && : -c --statistics -o cs.gmo cs.po mv: cannot stat `t-cs.gmo': No such file or directory make[1]: *** [cs.gmo] Error 1 make[1]: Leaving directory `/home/daiane/LTIB/L2.6.24_1.2.1_SDK_042008/rpm/BUILD/e2fsprogs-1.34/po' make: *** [all-progs-recursive] Error 1 error: Bad exit status from /home/daiane/LTIB/L2.6.24_1.2.1_SDK_042008/tmp/rpm-tmp.66904 (%build) Answer: This error is caused by lack of the new version of package gettext. Install the gettext. For Ubuntu, the command line is: sudo apt-get install gettext But LTIB just recognize the existence of this package if it was installed before the LTIB installation. So, reinstall the LTIB. Question Compiling LTIB I got this error message: checking for glib-genmarshal... no configure: error: Could not find a glib-genmarshal in your PATH error: Bad exit status from /home/alan/ltib/tmp/rpm-tmp.48168 (%build) Answer: This error happen when you don't have glib2.0-dev in your system. To Ubuntu execute: sudo apt-get install libglib2.0-dev Question: How to convert an ELF binary to raw ARM binary? Answer: arm-none-linux-gnueabi-objcopy -O binary test.elf test.bin Question: How to inform to kernel to print all message on screen? Answer: echo 8 > /proc/sys/kernel/printk Question: How to disassembly an ARM binary? Answer: arm-none-linux-gnueabi-objdump -b binary -m arm -D test.bin Question: RedBoot returns invalid parameter: RedBoot> load -r -b 0x100000 zImage Using default protocol (TFTP) Can't load 'zImage': invalid parameter Answer: Verify if your tftp server is running correctly. If so, then verify if RedBoot network is configured correctly. You can use ping command to verify if communication with computer is working. Insert non-formatted text here Configure RedBoot to not use script and configure network: RedBoot> ^C RedBoot> fc Run script at boot: false Use BOOTP for network configuration: true. Update RedBoot non-volatile configuration - continue (y/n)? y ... Read from 0x07ee0000-0x07eff000 at 0xa1fe0000: . ... Erase from 0xa1fe0000-0xa2000000: . ... Program from 0x07ee0000-0x07f00000 at 0xa1fe0000: . RedBoot> Reset the board and then load the image Question: How can I test GPIO using a very simple test? Answer: You can find a very simple test here

Brief introduction on i.MX Android

L5.4.3_1.0.0 release is now available on IMX_SW landing page: BSP Updates and Releases -> Linux ->Linux L5.4.3_1.0.0. Documentation -> Linux -> Linux 5.4.3_1.0.0 Documentation Files available: # Name Description 1 imx-yocto-LF_L5.4.3_1.0.0.zip i.MX L5.4.3_1.0.0 for Linux BSP Documentation. Includes Release Notes, User Guide. 2 LF_v5.4.y-1.0.0_images_MX6QPDLSOLOX.zip i.MX 6QuadPlus, i.MX 6Quad, i.MX 6DualLite, i.MX 6Solox Linux Binary Demo Files 3 LF_v5.4.y-1.0.0_images_MX6SLLEVK.zip i.MX 6SLL EVK Linux Binary Demo Files 4 LF_v5.4.y-1.0.0_images_MX6UL7D.zip i.MX 6UltraLite EVK, 7Dual SABRESD, 6ULL EVK Linux Binary Demo Files 5 LF_v5.4.y-1.0.0_images_MX7ULPEVK.zip i.MX 7ULP EVK Linux Binary Demo Files  6 LF_v5.4.y-1.0.0_images_MX8MMEVK.zip i.MX 8M Mini EVK Linux Binary Demo Files  7 LF_v5.4.y-1.0.0_images_MX8MNEVK.zip i.MX 8M Nano EVK Linux Binary Demo Files  8 LF_v5.4.y-1.0.0_images_MX8MQEVK.zip i.MX 8M Quad EVK Linux Binary Demo files 9 LF_v5.4.y-1.0.0_images_MX8QMMEK.zip i.MX 8QMax MEK Linux Binary Demo files 10 LF_v5.4.y-1.0.0_images_MX8QXPMEK.zip i.MX 8QXPlus MEK Linux Binary Demo files 11 imx-scfw-porting-kit-1.2.10.1.tar.gz System Controller Firmware (SCFW) porting kit v1.2.10.1 for L5.4.3_1.0.0   Target board: MX 8 Series MX 8QuadXPlus MEK Board MX 8QuadMax MEK Board MX 8M Quad EVK Board MX 8M Mini EVK Board MX 8M Nano EVK Board MX 7 Series MX 7Dual SABRE-SD Board MX 7ULP EVK Board MX 6 Series MX 6QuadPlus SABRE-SD and SABRE-AI Boards MX 6Quad SABRE-SD and SABRE-AI Boards MX 6DualLite SDP SABRE-SD and SABRE-AI Boards MX 6SoloX SABRE-SD MX 6UltraLite EVK Board MX 6ULL EVK Board MX 6ULZ EVK Board MX 6SLL EVK Board   What’s New/Features: Please consult the Release Notes.   Known Issues: For known issues and more details please consult the Release Notes.   More information on changes of Yocto, see: README: https://source.codeaurora.org/external/imx/imx-manifest/tree/README?h=imx-linux-zeus ChangeLog: https://source.codeaurora.org/external/imx/imx-manifest/tree/ChangeLog?h=imx-linux-zeus