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:
We are pleased to announce that Config Tools for i.MX v24.12 are now available. Downloads & links To download the installer for all platforms, please login to our download site via:  https://www.nxp.com/design/designs/config-tools-for-i-mx-applications-processors:CONFIG-TOOLS-IMX Please refer to  Documentation  for installation and quick start guides. For further information about DDR config and validation, please go to this  blog post. Release Notes Full details on the release (features, known issues...) • DDR tool – Support for the custom System Manager image import is added. – i.MX 95 advanced tests are enabled: Vref for DQ and Vref for CA optimization • SerDes tool – Additional parameters for TX configuration on GUI (swing, margin, equalization) for i.MX 95 are added. – PCIe Gen1/Gen2/Gen3 switch on pattern generation. • Clocks – Modular clocks initialization is supported. – Initialization mode is visible in the Clocks diagram and Details view. – New Modular Initialization view for configuration of the initialization mode and core selection of the module is created. • TEE – Configuration and overview of areas with the same address and different address space is supported. – Code generation can be toogled for global options groups. – The process for releasing ELE crypto before setting up TRDC is supported. • Pins – Miscellaneous tab for various Pins configuration options is added. – Filtering for routing dialogs is added.
View full article
This guide walks you through setting up and building the Yocto SDK, customizing a device tree (DTS), and compiling the kernel for NXP i.MX platforms. It is designed to simplify the process, from downloading tools to creating functional images for embedded devices. Prerequisites Required Software: A Linux-based operating system (Ubuntu/Debian recommended). Git installed (sudo apt install git). Yocto dependencies: $ sudo apt install gawk wget git diffstat unzip texinfo gcc build-essential chrpath socat cpio python3 python3-pip python3-pexpect xz-utils debianutils iputils-ping python3-git python3-jinja2 python3-subunit zstd liblz4-tool file locales libacl1 ​ Hardware: An NXP i.MX-based development board (i.MX6, i.MX7, i.MX8, or i.MX9). Sufficient storage space   1. Downloading the Repository Start by downloading the necessary tools and repository. If the ~/bin folder does not already exist, create it: $ mkdir ~/bin (this step may not be needed if the bin folder already exists) $ curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo $ chmod a+x ~/bin/repo $ export PATH=~/bin:$PATH   2. Compile the Yocto SDK: Create and navigate to a release directory: $: mkdir <release> $: cd <release>   Initialize and sync the repo: $: repo init -u https://github.com/nxp-imx/imx-manifest -b <branch name> [ -m <release manifest>] $: repo sync   Set up the environment and build the SDK: $: [MACHINE=<machine>] [DISTRO=fsl-imx-<backend>] source ./imx-setup-release.sh -b bld-<backend> $: bitbake <image recipe> -c populate_sdk   Example: $: mkdir Yocto_SDK $: cd Yocto_SDK $: repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-scarthgap -m imx-6.6.52-2.2.0.xml $: repo sync $: MACHINE=imx93evk DISTRO=fsl-imx-xwayland source ./imx-setup-release.sh -b bld-xwayland $: bitbake imx-image-full -c populate_sdk   Recommendation: Use the full image (imx-image-full) to include all available packages and libraries.   Run the generated .sh file to install the SDK: sudo ./fsl-imx-xwayland-glibc-x86_64-imx-image-full-armv8a-imx93evk-toolchain-6.6-scarthgap.sh   The final .sh file is located in: bld-xwayland/tmp/deploy/sdk/   3. Cloning the Kernel Repository (linux-imx repository)   Clone the kernel source matching the version of the Yocto SDK you built earlier:   $: git clone https://github.com/nxp-imx/linux-imx.git -b <Kernel-version>   EXAMPLE: $: git clone https://github.com/nxp-imx/linux-imx.git -b lf-6.6.52-2.2.0   4. Customizing the Device Tree Device trees can be modified or created based on your hardware setup.   Device Tree Locations:   iMX6 and iMX7: arch/arm/boot/dts/nxp/imx/   iMX8 and iMX9: arch/arm64/boot/dts/freescale/   If you create a new device tree, add it to the respective Makefile:   iMX8 and iMX9: arch/arm64/boot/dts/freescale/Makefile   iMX6 and iMX7: arch/arm/boot/dts/nxp/imx/Makefile     5. Setting Up the Cross-Compilation Environment To prepare for kernel compilation, source the environment setup script. Assuming the Yocto SDK is installed in /opt, run:   EXAMPLE: $ source /opt/fsl-imx-xwayland/6.6-scarthgap/environment-setup-armv8a-poky-linux   6. Configuring the Kernel Make configuration adjustments as needed:   iMX8 and iMX9: arch/arm64/configs/imx_v8_defconfig   iMX6 and iMX7: arch/arm/configs/imx_v7_defconfig   Use the appropriate configuration command:   iMX8 and iMX9: $: make imx_v8_defconfig   iMX6 and iMX7: $: make imx_v7_defconfig   7. Compiling Device Trees Only   To compile only the device tree files, run: $: make dtbs   8. Compiling the Kernel Finally, compile the kernel image using: $ make -j $(nproc)   The resulting kernel image will be located in: iMX8 and iMX9: arch/arm64/boot/   iMX6 and iMX7: arch/arm/boot/   References: IMX YOCTO PROJECT USERS GUIDE IMX LINUX USERS GUIDE  IMX REFERENCE MANUAL   
View full article
Kindly note that application note “AN12812: Using Code-Signing Tool with Hardware Security Module" has been removed from nxp.com. The AN is obsolete, the CST User’s guide describes how to use CST with an HSM using PKCS#11 interface. You can download CST package with its documentation from https://www.nxp.com/webapp/sps/download/license.jsp?colCode=IMX_CST_TOOL_NEW  
View full article
Hello everyone, this post is intended to add support to one of the most popular NFC chips on the market (PN532).  On this example I will use the I.MX93 EVK as reference board and focused in I2C communication for the PN532 Chip.    Details:   I.MX93 EVK  PN532 Module (I2C, SPI, UART)  BSP Linux 6.6.36_2.1.0 (Yocto)      STEP 1 (IMAGE COMPILATION).    At first, we need to compile our image for our board (in my case I.MX93 EVK) to add the NFC layer (Details on Yocto User's Guide😞😞 $ mkdir yocto-bsp $cd yocto-bsp $ repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-scarthgap -m imx-6.6.36-2.1.0.xml $ repo sync $DISTRO=fsl-imx-wayland MACHINE=imx93evk source imx-setup-release.sh -b imx93evk-build   Then, add the support for NFC in our local.conf file:  $ nano conf/local.conf   We will add the below lines: CORE_IMAGE_EXTRA_INSTALL += "libnfc" CORE_IMAGE_EXTRA_INSTALL += "libnfc-dev"   Then, we can compile the image with:  $ bitbake imx-image-full   NOTE:  libnfc is a complete coverage of low-level PN53x chipset commands written in pure and plain C for portability and speed.  libnfc-dev are the development files and headers to use in our low-level applications.    By default, the NXP BSP support the NFC pn532 driver with a tool called nfctool, but this one is very limited compared with the libnfc.      STEP 2 (DEVICE TREE MODIFICATION).    We need to add the below lines to the Device tree:  &lpi2c5 { #address-cells = <1>; #size-cells = <0>; clock-frequency = <400000>; pinctrl-names = "default", "sleep"; pinctrl-0 = <&pinctrl_lpi2c5>; pinctrl-1 = <&pinctrl_lpi2c5>; status = "okay"; nfc@24 { compatible = "nxp,nxpnfc"; //we can set the "nxp,pn533" driver but it will just work for the nfctool mentioned before reg = <0x24>; clock-frequency = <400000>; interrupt-parent = <&gpio2>; interrupts = <18 IRQ_TYPE_EDGE_FALLING>; }; };    And to the iomux section(same in device tree):  pinctrl_lpi2c5: lpi2c5grp { fsl,pins = < MX93_PAD_GPIO_IO22__LPI2C5_SDA 0x40000b9e MX93_PAD_GPIO_IO23__LPI2C5_SCL 0x40000b9e MX93_PAD_GPIO_IO18__GPIO2_IO18 0x31e >; };     STEP 3 (Connection with PN532 MODULE).     For this example, we must connect the Module with the I.MX93 RP Header as follows:    I.MX93 SIDE  PN532 SIDE  GND  GND  VCC  VCC  GPIO_IO22  SDA  GPIO_IO23  SCL  GPIO_IO18  IRQ    STEP 4 (BOOT BOARD AND CREATE libnfc.conf FILE).    Once when we have booted our board and selected our modified Device Tree, we should see our i2c-4 under /dev of our Linux OS: root@imx93evk:~# ls /dev | grep i2c i2c-0 i2c-1 i2c-2 i2c-4   And see our specific device (0x24) with the i2cdetect tool:   root@imx93evk:~# i2cdetect -y 4 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- 24 -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- --     Now, we need to create a file called libnfc.conf under /etc/nfc/ (You can create that directory if does not exist).  This file must contain information about how the libnfc layer will communicate with the i2c device:    # Allow device auto-detection (default: true) # Note: if this auto-detection is disabled, user has to set manually a device # configuration using file or environment variable allow_autoscan = false # Allow intrusive auto-detection (default: false) # Warning: intrusive auto-detection can seriously disturb other devices # This option is not recommended, user should prefer to add manually his device. allow_intrusive_scan = true # Set log level (default: error) # Valid log levels are (in order of verbosity): 0 (none), 1 (error), 2 (info), 3 (debug) # Note: if you compiled with --enable-debug option, the default log level is "debug" log_level = 2 # Manually set default device (no default) # To set a default device, you must set both name and connstring for your device # Note: if autoscan is enabled, default device will be the first device available in device list. #device.name = "_PN532_SPI" #device.connstring = "pn532_spi:/dev/spidev0.0:500000" device.name = "_PN532_I2c" device.connstring = "pn532_i2c:/dev/i2c-4"   As you can see, the most important line to modify is the device.connstring, that is the charged of interaction and connection between the PN53x Module and the libnfc layer. In my case is pn532_i2c:/dev/i2c-4.    Now we can use the NFC module:  root@imx93evk:~# nfc-list nfc-list uses libnfc 1.8.0 NFC device: _PN532_I2c opened root@imx93evk:~#   And read UID of TAGs:  root@imx93evk:~# nfc-poll nfc-poll uses libnfc 1.8.0 NFC reader: _PN532_I2c opened NFC device will poll during 36000 ms (20 pollings of 300 ms for 6 modulations) ISO/IEC 14443A (106 kbps) target: ATQA (SENS_RES): 00 44 UID (NFCID1): 04 17 b5 d2 a2 11 90 SAK (SEL_RES): 00 Waiting for card removing...nfc_initiator_target_is_present: Target Released done. root@imx93evk:~#   Also, attached is a little application using the NFC headers installed with libnfc-dev. Tha application will do a poll with a 10 seconds time out. If Tag is not detected in 10 seconds, the app will close. If a tag is detected before the timeout, the app will print the UID of the NFC TAG:   OUTPUT of timeout: root@imx93evk:~# ./nfc-app NFC reader: _PN532_I2c opened Waiting for an NFC tag (timeout: 10 seconds)... No NFC tag detected within the timeout period. root@imx93evk:~#   OUTPUT when tag is detected: root@imx93evk:~# ./nfc-app NFC reader: _PN532_I2c opened Waiting for an NFC tag (timeout: 10 seconds)... Tag detected - UID: 04:16:BC:D2:A2:11:90 root@imx93evk:~#   To compile the app just copy the attached nfc-app.c file to the i.MX93 EVK and compile using this command: root@imx93evk:~# gcc nfc-app.c -o nfc-app -lnfc     I hope this thread can be helpful!   Best regards, Salas.  
View full article
Please notice the following patches are only tested in the environment that is listed below. For the environment with other software versions or hardware equipment, some other editing  may be required Environment: i.MX 8MP EVK LVDS:LVDS BOE EV121WXM-N10-1850  LVDS to MiniSAS panel:XMX-LVDS-MINISAS Software: LF5.15.71 U-boot: 1. Apply '0001-Enable-DY1212W-4856-in-U-boot-for-i.MX8MP.patch' to enable EV121WXM-N10-1850  in U-boot stage. If other LVDS panel is used here, you will need porting your specific LVDS device in this step. 2. Apply '0002-Modify-u-boot-to-show-logo-seamlessly-for-i.MX8MP.patch' to make sure display related models won't be power off, which will help to achieve seamless display. 3. In the original U-boot driver, PWM isn't enable. Therefore, apply '0003-Enable-PWM-and-BACKLIGHT-in-U-boot-and-modify-to-sho.patch' to enable PWM. Kernel: 1. Apply '0001-Enable-DY1212W-4856-in-Kernl-for-i.MX8MP.patch' to enable EV121WXM-N10-1850  in Kernel. If other LVDS panel is used here, you will need porting your specific LVDS device in this step. 2. Apply '0002-Modify-Kernel-to-show-logo-seamlessly-for-i.MX8MP.patch' to make sure LVDS related models won't be init in the booting progress. 3. Apply '0003-Enable-PWM-and-BACKLIGHT-in-Kernel-and-modify-to-sho.patch' to make sure we could edit backlight of panel in Kernel. 
View full article
Please notice the following patches are only tested in the environment that is listed below. For the environment with other software versions or hardware equipment, some other editing  may be required Environment: i.MX 93 EVK LVDS:LVDS BOE EV121WXM-N10-1850  Software: LF6.1.36 U-boot: 1. Apply '0001-Add-LVDS-driver-and-BOE-12.1-EV121WXM-N10-1850-LVDS-.patch' to enable EV121WXM-N10-1850  in U-boot stage. If other LVDS panel is used here, you will need porting your specific LVDS device in this step. 2. Apply '0002-Modify-u-boot-to-show-logo-seamlessly.patch' to make sure display related models won't be power off, which will help to achieve seamless display. Kernel: 1. Apply '0001-Keep-NXP-logo-until-Weston-is-booted-for-i.MX93-in-L.patch' to make sure LVDS related models won't be init in the booting progress.
View full article
Please notice the following patches are only tested in the environment that is listed below. For the environment with other software versions or hardware equipment, some other editing  may be required Environment: i.MX 8MP EVK MIPI DSI: MX8-DSI-OLED1 (RM67191) Software: LF5.15.71 U-boot: 1. Apply '0001-Modify-u-boot-to-show-logo-seamlessly.patch' to make sure display related models won't be power off, which will help to achieve seamless display. Kernel: 1. Apply '0001-Keep-NXP-logo-until-Weston-is-booted-8MP-MIPI.patch' to make sure MIPI-DSI related models won't be re-init in the booting progress.
View full article
This article demonstrates several simple gpio leds as system indicators, including kernel panic indicators.   HW: i.MX93 11x11 EVK SW: lf-6.6.3-1.0.0    
View full article
    Test envs: BOARD: i.MX 8MN EVK BSP: L6.6.36   The L6.6.y includes the feature about supporting starting Cortex-M33 from non-TCM address for i.MX93, but not for i.MX8M series.    LF-7815 remoteproc: imx_rproc: support starting Cortex-M33 from non-TCM address for i.MX93 https://github.com/nxp-imx/linux-imx/commit/680aa11c7bdaddf6bbffd74bc0a94ef67593b69b#diff-66a34e17e82d281936f559217adc3983b39abeb2e478967f3d5cef2eed5b67fcR693   For older BSP, customer can refer this full patch set https://patchew.org/linux/20230209063816.2782206-1-peng.fan@oss.nxp.com/   If you want to test ELF in DDR on i.MX8M series and i.MX93 platform with L6.6.y, please use below patch set.  
View full article
Introduction LVGL is a graphics library to run on devices using a limited amount of resources. Previously, we have ran an LVGL demo from the LVGL repository, this contains a couple more demos which all of them are pieces of code included and lends us the opportunity to evaluate the library in a quick and easy way. GUI projects are developed by customers through a lot more options than bare code, there are GUI tools that translate a graphic asset into LVGL code, in this demonstration we will use a tool that's widely used in MCU GUI development and translate the GUI created into LVGL code; SquareLine. NOTE: refer to the appendix for precedent LVGL documents on i.MX series processors. HW set-up i.MX 93 EVK boot over eMMC/uSD to Linux Factory or Ubuntu. Connect power and debug receptables. Connect MX8_DSI_OLED1 to J701 (MIPI DSI) through MiniSAS cable. SquareLine set-up Download the latest version of SquareLine under the following link according to your host system. NOTE: This document is intended for demonstration of templates included within the tool, so it's recommended to download a free trial, for formal development please refer to the appendix of this document. Unzip and execute the installer, this is the windows prompt.   Demo download After setting SquareLine up go to the example section, we will demonstrate the thermostat capabilities with the Thermostat Demo. We can directly export these UI files and they would be graphically ready to be build, click on Export -> Export UI Files and select your preferred destination to save these.   LVGL setup. Option 1 Fresh Environment Clone LVGL and LV_DRIVERS repositories, this is a .gitmodules file that points to the specific branches needed. [submodule "lvgl"] path = lvgl url = https://github.com/lvgl/lvgl.git branch = release/v8.3 [submodule "lv_drivers"] path = lv_drivers url = https://github.com/lvgl/lv_drivers.git branch = release/v8.3 NOTE: If you are using other methods, you should point to these commits, lv_drivers @ 8cdabe8 and lvgl @ f2c1032. Gather the necessary files described below from the LVGL Linux Port example found here. Makefile lv_conf.h lv_drv_conf.h main.c mouse_cursor_icon.c Patch the Makefile. + include $(LVGL_DIR)/thermostat/thermostat.mk Patch the lv_drv_conf.h # define EVDEV_NAME "/dev/input/event10" /*You can use the "evtest" Linux tool to get the list of devices and test them*/ +# define EVDEV_NAME "/dev/input/event<Number>" NOTE: This changes according to the output of # evtest. Patch lv_conf.h -#define LV_FONT_MONTSERRAT_20 0 +#define LV_FONT_MONTSERRAT_20 1 Patch the main.c - disp_drv.hor_res = 800; - disp_drv.ver_res = 480; + disp_drv.hor_res = 1080; + disp_drv.ver_res = 1920; … - /*Create a Demo*/ - lv_demo_widgets(); + /*Create a Squareline Demo*/ + ui_init(); LVGL Setup. Option 2 with LVGL demos already running Gather the necessary files described below from the LVGL Linux Port example found here. Makefile lv_conf.h lv_drv_conf.h main.c mouse_cursor_icon.c Patch the lv_drv_conf.h # define EVDEV_NAME "/dev/input/event10" /*You can use the "evtest" Linux tool to get the list of devices and test them*/ +# define EVDEV_NAME "/dev/input/event<Number>" NOTE: This changes according to the output of # evtest. Patch the main.c - disp_drv.hor_res = 800; - disp_drv.ver_res = 480; + disp_drv.hor_res = 1080; + disp_drv.ver_res = 1920; … - /*Create a Demo*/ - lv_demo_widgets(); + /*Create a Squareline Demo*/ + ui_init(); Run the demo Build the demo with the following command and copy the ./demo output to the i.MX 93 EVK RootFS. # source /opt/path/to/your/toolchain # make clean # make The demo can be ran with the following commands. # systemctl stop weston # For LF $ sudo service gdm3 stop # For Ubuntu # ./demo   Conclusion SquareLine demos can run in prebuilt and basic builds of i.MX processors through FB, which can enable a quick set-up for GUI testing before moving to use a windowing stack without sacrificing any features. Appendix Document: How to run LGVL on iMX using framebuffer Official page for pricing information
View full article
some customers have issue with uboot resetting on new bsp because of lack of mac address and different design fom nxp evk board, this doc shows how to set the mac address in different way(fuse, dts file, header file), then check the different HW design between customized board with nxp board, according to the HW design to change the uboot 
View full article
  JEIDA-24 is adopted in most use-cases, and also the default format in Linux BSP(6.x)  Actually, JEIDA-18 is also supported in Linux BSP by not mentioned explicitly.   JEIDA-18 can be supported in two configuration: 1. Keep JEIDA-24 setting to display controllers, skip 4th data-lane in hardware connection: according JEIDA-24 output waveform, it has 4 data-lane enabled on LVDS bus: since the data-bits on TxOUT3 are the LSBs of the pixels, to change from JEIDA-24(RGB888, 4 data-lane) to JEIDA-18(RGB666, 3 data-lane), it can be achieved by skipping the TxOUT3 output(4th data-lane) in hardware connection, to make the JEIDA-18 format as the picture below(JEIDA-18 LCD panels only require 3 data-lanes)   2. Change the display controller settings to JEIDA-18: one reference by Variscite, one of the SoM vendor: https://variwiki.com/index.php?title=DART-MX8M-PLUS_Display&release=mx8mp-yocto-mickledore-6.1.36_2.1.0-v1.3 related setting quoted from the link above: Supported "data-mapping" values are "jeida-18", "jeida-24" and "vesa-24". Supported "fsl,data-mapping" values are "jeida", and "spwg". Supported "fsl,data-width" values are <18>, and <24>.    "data-mapping"= "jeida-18", "jeida-24" and "vesa-24" are handled in DRM driver, as the link below: https://github.com/nxp-imx/linux-imx/blob/d23d64eea5111e1607efcce1d601834fceec92cb/drivers/gpu/drm/drm_of.c#L451 if (!strcmp(mapping, "jeida-18")) return MEDIA_BUS_FMT_RGB666_1X7X3_SPWG; if (!strcmp(mapping, "jeida-24")) return MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA; if (!strcmp(mapping, "vesa-24")) return MEDIA_BUS_FMT_RGB888_1X7X4_SPWG;    Here the variable “MEDIA_BUS_FMT_RGB666_1X7X3_SPWG" is handled in ldb driver(MX8MP) as the link below: https://github.com/nxp-imx/linux-imx/blob/d23d64eea5111e1607efcce1d601834fceec92cb/drivers/gpu/drm/bridge/fsl-ldb.c#L144 switch (bridge_state->output_bus_cfg.format) { case MEDIA_BUS_FMT_RGB666_1X7X3_SPWG: lvds_format_24bpp = false; lvds_format_jeida = true; break; case MEDIA_BUS_FMT_RGB888_1X7X4_JEIDA: lvds_format_24bpp = true;  the bus_format would be "MEDIA_BUS_FMT_RGB666_1X18" in this configuration:  https://github.com/nxp-imx/linux-imx/blob/d23d64eea5111e1607efcce1d601834fceec92cb/drivers/gpu/drm/imx/imx8mp-ldb.c#L178 switch (ldb_ch->bus_format) { case MEDIA_BUS_FMT_RGB666_1X7X3_SPWG: imx_crtc_state->bus_format = MEDIA_BUS_FMT_RGB666_1X18; break;    “MEDIA_BUS_FMT_RGB666_1X18” is not handled in LCDIF driver:  https://github.com/nxp-imx/linux-imx/blob/d23d64eea5111e1607efcce1d601834fceec92cb/drivers/gpu/imx/lcdifv3/lcdifv3-common.c#L310 switch (bus_format) { case MEDIA_BUS_FMT_RGB565_1X16: disp_para |= DISP_PARA_LINE_PATTERN(LP_RGB565); break; case MEDIA_BUS_FMT_RGB888_1X24: disp_para |= DISP_PARA_LINE_PATTERN(LP_RGB888_OR_YUV444); break; default: dev_err(lcdifv3->dev, "unknown bus format: %#x\n", bus_format); return;    hence there would be error message below in this configuration, which can be ignored: imx-lcdifv3 32e80000.lcd-controller: unknown bus format: 0x1009  
View full article
Hibernation mode (suspend to disk) will be useful for boot time optimization, especially under heavy application usage cases. This article is a quick guide for how to enable hibernation mode in Linux running on i.MX93. Some limitation and pitfalls will also be introduced.   Detail PDF attached.    
View full article
There are two ethernet ports in i.MX8MP: FEC0 and FEC1(eQOS). Normally we use iperf to test ethernets ports performance. However, when using tftp test, the result is different in two ports. This document describe how to fine tune parameters to increase speed under tftp test or other use case. It is suitable for most i.MX serials and most BSP version.
View full article
Customers are experiencing significant and unexpected performance issues in their applications running on Android 14 relative to the performance that they saw on older versions of the OS (such as A12 or A13). This is a known issue on Android Community and is note related to NXP implementation of AOSP (Android Open Source Project). The information Android 14 can recollect from any debuggable application is a lot. With the help of Perfetto you can get and incredible analysis of all processes running on Android OS or an analysis of the memory usages. All this features have a side effect on debuggable applications, where debuggable application can experiment low performance. The degradation on the performance is around 1.5x and 2.0x the time taken on a previous Android version. In order to take really measurements on the application performance it is necessary to disable those features when building the apk . Quick Workaround There are two ways of disabling debug features: Build a release variant by adding a dummy key to Android-Studio. Read the following link to get further details on how to do it. Set debuggable feature to false on build.gradle (Module :app) . Here an example: android { buildTypes { debug { applicationIdSuffix '.debug' debuggable false // The important line! } } } Rebuild the apk and installed to the target with adb install <my-apk> . The application should now have the same performances it was having with A13 or older. References: Debuggable APP lag after updating to Android14
View full article
Poring from MCIMX6Y2CVM05AB to MCIMX6Y1DVM05AB Backgroud: Our customers encounter Kernel stuck at starting kernel issue. Here is detail description as below: (1 )Using customer board, and the main chip is MCIMX6Y1DVM05AB. (2) MCIMX6Y2CVM05AB works fine using the same image. (3)The kernel version is L5.10.52. But the old L4.14.98 works fine. (4)Using imx6ull evk's dtb has the same symptom. (imx6ull-14x14-evk.dtb in L5.10.52 prebuild image from NXP. (5)The  L4.14.98 versionBSP both  MCIMX6Y1DVM05AB and MCIMX6Y2CVM05AB can work well For the L5.10.52 only the MCIMX6Y2CVM05AB can work​. Kernel crash at here:   Generally speaking, most customer need to porting from old chip to new, for this customer need to use porting from the new product to old products they have their reasons.     Two reasons: (1) Their previous project use MCIMX6Y1DVM05AB. And also have MCIMX6Y1DVM05AB stock. (2) And the customer needs 15kpcs for urgent demand. But there is no MCIMX6Y2CVM05AB stock in their city.​ Porting steps: For these two products, they are difference, but most pins to pins in design. 1\Found the difference for this two product: See the datasheet: https://www.nxp.com.cn/docs/en/data-sheet/IMX6ULLCEC.pdf https://www.nxp.com.cn/docs/en/data-sheet/IMX6ULLIEC.pdf     For the MCIMX6Y1DVM05AB do not have the LCD/CSI, one CAN, one Ethernet,one ADC.   2\Check the customer’s board dts setting and modify Ask customer for their Board dts file and check: The MCIMX6Y1DVM05AB chip has only followed features, so customer should make sure the related drivers are removed from dts. That means in climaxL5.10.52.7z, customer should disable the followed drivers: pxp, lcdif, can2. (csi and fec2 are already disabled) (1) Disable the fec2   (2)CSI disable   (3)Lcdif disable   (4)CAN 2 Remove     Result: After remove these unused functions. The MCIMX6Y1DVM05AB could boot well on customer’s board. If customer use the MCIMX6Y2CVM05AB, all these functions need to add.  
View full article
Config Tool Introduction and Use From i.MX93 using the Config Tool for the DDR configure. The Config Tools for i.MX is a suite of evaluation and configuration tools that help users from initial evaluation to production software development. Config Tools for i.MX is an easy-to-use way to configure the pins and DDR of the i.MX processor devices. The software, in general, enables you to create, inspect, change, and modify any aspect of the pin configuration and muxing of the device. It also allows you to configure and validate DDR settings. 1 Download and install The link in website: https://www.nxp.com/design/design-center/software/i-mx-developer-resources:IMXSW_HOME   The Config Tools for i.MX is installed as a desktop tool which then loads additional device information through a network connection, but does otherwise not need internet connection. It does not require a project setup, as all the settings are stored in text and generated source files, which then can be easily stored in a version control system or exchanged with other users. Config Tool function For the Config Tool have two function, one is the Pins tool another is the DDR tool functions. 1.1 Pins tool The Pins Tool makes pin configuration easier and faster with an intuitive and easy user interface, which then generates normal C code that can then be used in any C and C++ application. The Pins Tool configures pin signals from multiplexing (muxing) to the electrical properties of pins, and it also creates Device Tree Snippets Include (.dtsi) files and reports in CSV format. Pins Tool Configuration of pin routing/muxing Managing different functions used for routing initialization Configuration of pin functional/electrical properties Generation of code for routing and functional/electrical properties 1.2 DDR Tool   The DDR tool provides two main functionalities: configuration and validation. The DDR configuration provides a user-friendly graphical interface to configure the DDR controller and the DDR PHY. It can be used for tweaking some of the configuration parameters when you want to use different memory modules than the ones received with the board or when you want to optimize the configuration. DDR validation provides different scenarios to verify the DDR performance, by downloading a test image to the processor’s internal RAM through a USB connection. The result is sent to the DDR tool via the UART. DDR validation can help verify DDR stability on the board in a non-OS environment.   DDR Tool The DDR tool is designed for: Configuration of DDR controllers Validation of DDR configuration Support for i.MX 8M and i.MX93 families Configuration: Simplified UI for device configuration Advanced board configuration options Stressing: Stress tests with overnight option Optimization: Sweep ODT configuration and optimization of Vref for DQ and CA Virtual Timing Signal Analysis (vTSA) support: RX and TX data eye, CA BUS signals margin and CA Eye test for LPDDR4 DRAM Generation of C code for U-boot SPL driver The DDR tool allows you to view and configure basic DDR attributes, such as memory type, frequency, number of channels and others and test the DDR configuration by a variety of tests. After you have specified the connection type, you can choose scenarios, tests to run in these scenarios, and view the test results, logs, and summary.         2 Install Download Config_Tools_for_i.MX_v16_x64.exe   Note: In our company PC we need to apply the Admin Manage:   Config Tools for i.MX is available offline (local)  Minimum system requirements One of the following graphical operating systems: – Microsoft Windows 10 (64-bit) – Ubuntu 22.04 LTS Note: Linux-hosted variants of tools are distributed on Linux as 64-bit binaries, which may not work on 32-bit systems. – Supported desktop environments: GNOME – Mac OS X (12.x) 4 GB RAM Display with resolution 1024 x 768 Internet connection for dynamic download from processor database Note: If the MacOS is set to Traditional Chinese, Config Tools for i.MX starts in English and not Chinese. This is intended. 2 The use of the Config tool Configuration of DDR controllers 2.1 Creating a new configuration create a configuration from the Start development wizard or by selecting File > New from the Menubar. If you start creating your development for any NXP board or kit, we recommended you start with example to create a configuration for a board or a kit. Such configuration contains board-specific settings. If you select a processor, the configuration will be empty. 2.2 Run the Config tool Open the Config tool, choose the Creating a new standalone configuration for a processor, board, or kit   Choose the Processor   Choose the i.MX93 part number product     Choose DDR Under the tool select the tools---->DDR Three sections need to mentioned: Make DDR configure right and make the DDR is enabled already.   Two sections are very important the same as the tool we supply before in the old product: DDR paramaters configuration DDR stress test(Validation)   DDR parameters configuration:   This is the UART Port configure, for the i.MX93 EVK Board default use the UART1 for A55 core debug, if in customer’s design use others port can choose here and also need modify the register settings manually.       Advanced parameters config, it is very important:   General advice The I2C connection between MX and PMIC should be consistent with the development board, using the same pad. If choose different , Need to modify I2C     Validation of DDR configuration In the previous DDR stress test tool, only two functions were provided: DDR calibration and stress test. In the new Config tool, more testing items are provided for customers to debug DDR, totaling four items.   When finished the DDR configuration then go to do the validation.     Test DDR initialization script, Perform basic read and write operations   If pass the test, it will be OK. If failed, we need to fail shooting for it. According to the log output information, check boot mode/UART/USB, etc If the test fails, first check the boot mode configuration and UART/USB interface. The previous DDR stress test tool would output statements such as "Please set in serial download mode" or "Please connect UART port", which are obvious. The current Config tool outputs all log information of the code, with a lot of content and no erroneous conclusions. We need to carefully review the log output to identify where the problem lies. Test on the i.MX93 EVK Board, if the boot mode not right and the USB is not connected, when do the test there will be the ERROR Messages in the logs:   Test on the i.MX93 EVK Board, if not with proper UART port, the ERROR Messages in the logs:   Optimization test This requires detailed ODT, driver strength testing, and scanning of all DQ IO configuration options, Test whether each configuration is passed or failed. Finally, output the mapping between the read/write drive strength and ODT output. For the test result when reading, the impedance of DRAM driven strength and PHY ODT cannot be set too big, (Green - pass, Orange - fail)   When determining the optimal ODT/driver strength value for the customer's board, this mapping diagram can be used as a reference, but it cannot be the sole basis for making this decision. If the customer fully references the NXP development board for design, they can first use the default configuration of the development board for testing. Then fine tune it.     VTSA (Virtual Timing Signal Analysis) Generate write and read data eye diagrams by running a series of write/read operations. (Different from using a high-speed oscilloscope for manual physical TSA (pTSA) measurement). Use the DDR controller itself to test margin by writing margin (Diag Write Margin)/diagnosing read margin (Diag Draw a virtual data eye diagram for each DQ channel during the Read Margin test. This tool differs from the actual eye diagram results and is for reference only.     DDR Stress Test The last step, stress test, customer can choose long time test:     Code generate In the right side we can see the lpddr4_timing.c generate, using for the uboot. For this tool, the code can be automatically generated and automatically generated code when the registers change, and do not need to run the test on the board, this is difference with the old tool.   3 i.MX93 UBOOT and Kernel DDR configuration 3.1 The DDR configuration in the Uboot (1) Copy the generated lpddr4x_timing.c to uboot path: board/freescale/imx93_evk/lpddr4x_timing.c       (2) DDR Size setting uboot-imx/include/configs/imx93_evk.h The default size is 2GB for the i.MX93 EVK board.   For the i.MX93EVK uses 2GB LPDDR4X. If using 1GB/512MB LPDDR4, it is important to note that the size of the DDR is related to the memory map address.   According to the Memory map, starting from 0xC000_0000 is 1GB of DRAM space, and starting from 0xA000_0000 is 512MB of DRAM space.               3.2 The DDR configuration align in the Kernel For the 1GB LDDR4/4X device tree modify For the i.MX93 the NPU is accessed through M-core, so a section of DRAM memory is reserved. Regardless of whether NPU is used or not, ethos must be changed here, otherwise starting the kernel may result in errors. Change the address space to within 1GB and appropriately reduce the memory allocation size. arch/arm64/boot/dts/freescale$ vi imx93-11x11-evk.dts         Summary: Config tool is NXP's new DDR script generation/stress testing/OMUX allocation tool, which is required for i.MX93. Other i MX chips can also use this tool. The Config tool provides more DDR testing projects, including testing ODT/driver capabilities and outputting mapping maps, generating DDR virtual eye diagrams, etc., making it easy to test DDR conditions from multiple perspectives. It is recommended to use the Config tool to debug ODT/driver capabilities and other parameters, which is also applicable to all i MX chip, as a debugging tool for reference. The theoretical parameters of the actual board should refer to the simulation results of the board or the measured results of DDR signals. Any questions contact us freely.  
View full article