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    

    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.  

 

 

 

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

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 

  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  

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.    

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.

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

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.  

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.  

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. NOTE: Please note that DDR support for the i.MX 8M Family and has also been added in the Config Tools for i.MX Applications Processors | NXP Semiconductors Please consider using this tool with more enhanced features. i.MX 8M Family DDR Tools Overview The i.MX 8M Family DDR Tool is a Windows-based software to help users to do LPDDR4/DDR4/DDR3L training, stress test and DDR initial code generation for u-boot SPL. This page contains the latest releases for the i.MX 8M Family DDR Tools and cover the following SoCs : i.MX 8M Quad and its derivatives i.MX 8M Quadlite and i.MX 8M Dual i.MX 8M Mini Quad and its derivatives i.MX 8M Mini Quadlite/Dual/DualLite/Solo/SoloLite  i.MX 8M Nano Quad and its derivatives i.MX 8M Nano Quadlite/Dual/DualLite/Solo/SoloLite  i.MX 8M Plus   NOTE: For the i.MX 8/8X Family of DDR tools please refer to the: i.MX 8/8X Family DDR Tools Release   The purpose of the i.MX 8M Family DDR Tools is to enable users to generate and test a custom DRAM initialization based on their device configuration (density, number of chip selects, etc.) and board layout (data bus bit swizzling, etc.).  This process equips the user to then proceed with the bring-up of a boot loader and an OS.  Once the OS is brought up, it is recommended to run an OS-based memory test (like Linux memtester) to further verify and test the DDR memory interface.     The i.MX 8M Family DDR Tools consist of: DDR Register Programming Aid (RPA) MSCALE DDR Tool   For more details regarding these DDR tools and their usage, refer to the i.MX 8M DDR Tools User Guide.   i.MX 8M Family DDR Tool    The i.MX 8M Family DDR stress test tool is a Windows-based software tool that is used as a mechanism to verify that the DDR initialization is operational for use with u-boot and OS bring-up. To install the DDR Stress Test, save and extract the zip file mscale_ddr_tool_vXXX_setup.exe.zip   (where 'xxx' is the current version number) and follow the on-screen installation instructions.   i.MX 8M Family DDR Tool Requirements   The tool requires access to the Windows registry, hence users must run it in administrator mode. When users design new i.MX 8M Family boards, please make sure to follow the rules outlined in the respective Hardware Developers Guide and the MSCALE_DDR_Tool_User_Guide, which can help users bring up DDR devices on their respective i.MX 8M boards.   i.MX 8M Family DDR Tool User Guide   The i.MX 8M DDR tool includes the document: MSCALE_DDR_Tool_User_Guide NOTE: Please read the MSCALE_DDR_Tool_User_Guide inside the package carefully before you use this tool.   i.MX8M DDR Tool Revision History   Rev Major Changes* (Features) Comments 3.31 Integration of the workaround for 8MQ ERR051273   3.30 Fix DBI enabled issue for all i.MX 8M series Automatically identify ROHM and PCA9450 PMICs on i.MX 8M Nano board Fix 4GB/8GB memory tester issues   3.20 Add support to i.MX 8M Plus   3.10 Fixe UART communication issues for some specific characters between the PC software and the target board. Fine-tune DDRPHY registers in generated C code.   3.00 Add support to i.MX8M-nano Add support to different PMIC or PMIC configuration Add support to stress test for all DDR frequency points RPA tools for Nano include support for DDR3L, DDR4, and LPDDR4.   Note that the DDR3L and LPDDR4 RPAs contain the name preliminary only to denote that these RPAs are based on internal NXP validation boards where the DDR4 RPA is based on the released EVK.   2.10 Change DDR4 capacity computing method   2.00 Add support to i.MX8M-mini   * Further details available in the release notes   Sample configuration in the .ds script for i.MX 8M debug UART2: ################step 0: configure debug uart port. Assumes use of UART IO Pads.   ##### ##### If using non-UART pads (i.e. using other pads to mux out the UART signals), ##### ##### then it is up to the user to overwrite the following IO register settings   ##### memory set 0x3033023C 32 0x00000000 #IOMUXC_SW_MUX_UART2_RXD memory set 0x30330240 32 0x00000000 #IOMUXC_SW_MUX_UART2_TXD memory set 0x303304A4 32 0x0000000E #IOMUXC_SW_PAD_UART2_RXD memory set 0x303304A8 32 0x0000000E #IOMUXC_SW_PAD_UART2_TXD memory set 0x303304FC 32 0x00000000 #IOMUXC_SW_MUX_UART2_SEL_RXD sysparam set debug_uart   1 #UART index from 0 ('0' = UART1, '1' = UART2, '2' = UART3, '3' = UART4)   Sample configuration in the front of the .ds script for i.MX 8M debug UART3  ################step 0: configure debug uart port. Assumes use of UART IO Pads.   ##### ##### If using non-UART pads (i.e. using other pads to mux out the UART signals), ##### ##### then it is up to the user to overwrite the following IO register settings   ##### memory set 0x30330244 32 0x00000000 #IOMUXC_SW_MUX_UART3_RXD memory set 0x30330248 32 0x00000000 #IOMUXC_SW_MUX_UART3_TXD memory set 0x303304AC 32 0x0000000E #IOMUXC_SW_PAD_UART3_RXD memory set 0x303304B0 32 0x0000000E #IOMUXC_SW_PAD_UART3_TXD memory set 0x30330504 32 0x00000002 #IOMUXC_SW_MUX_UART3_SEL_RXD sysparam set debug_uart   2 #UART index from 0 ('0' = UART1, '1' = UART2, '2' = UART3, '3' = UART4)   Sample configuration in the front of the .ds script for i.MX 8M Mini PMIC configuration: ##############step 0.5: configure I2C port IO pads according to your PCB design.   ##### ########### You can modify the following instructions to adapt to your board PMIC ####### memory set 0x30330214 32 0x00000010  #IOMUXC_SW_MUX_I2C1_SCL memory set 0x30330218 32 0x00000010  #IOMUXC_SW_MUX_I2C1_SDA memory set 0x3033047C 32 0x000000C6 #IOMUXC_SW_PAD_I2C1_SCL memory set 0x30330480 32 0x000000C6  #IOMUXC_SW_PAD_I2C1_SDA sysparam set pmic_cfg 0x004B #bit[7:0] = PMIC addr,bit[15:8]=I2C Bus. Bus index from 0 ('0' = I2C1, '1' = I2C2, '2' = I2C3, '3' = I2C4) sysparam set pmic_set 0x2F01 #bit[7:0] = Reg val, bit[15:8]=Reg addr. #REG(0x2F) = 0x01 sysparam set pmic_set 0x0C02   #REG(0x0C) = 0x02 sysparam set pmic_set 0x171E   #REG(0x17) = 0x1E sysparam set pmic_set 0x0C00   #REG(0x0C) = 0x00 sysparam set pmic_set 0x2F11    #REG(0x2F)=0x11     i.MX 8M Family DDR Register Programming Aid (RPA) The i.MX 8M DDR RPA (or simply RPA) is an Excel spreadsheet tool used to develop DDR initialization for a user’s specific DDR configuration (DDR device type, density, etc.). The RPA generates the DDR initialization(in a separate Excel worksheet tab):   DDR Stress Test Script: This format is used specifically with the DDR stress test by first copying the contents in this worksheet tab and then pasting it to a text file, naming the document with the “.ds” file extension. The user will select this file when executing the DDR stress test. The How to Use Excel worksheet tab provides instructions on using the RPA   i.MX 8M Family DDR Register Programming Aid (RPA): Current Versions To obtain the latest RPAs, please refer to the following links (note, existing RPAs have been removed from this main page and moved to the SoC specific links below): i.MX 8M Quad : https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8M-m850D-DDR-Register-Programming-Aid-RPA/ta-p/1172441 i.MX 8M Mini : https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8MMini-m845S-DDR-Register-Programming-Aid-RPA/ta-p/1172443 i.MX 8M Nano: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8MNano-m815S-DDR-Register-Programming-Aid-RPA/ta-p/1172444 i.MX 8M Plus: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX-8MPlus-m865S-DDR-Register-Programming-Aids-RPA/ta-p/1235352   Processor Mask Revisions Memory Supported Latest RPA Version * i.MX 8M Quad & Derivatives All LPDDR4 Rev 33 i.MX 8M Quad & Derivatives All DDR4 Rev 18 i.MX 8M Quad & Derivatives All DDR3L Rev 9 i.MX 8M Mini & Derivatives A0 LPDDR4 Rev 22 i.MX 8M Mini & Derivatives A0 DDR4 Rev 21 i.MX 8M Mini & Derivatives A0 DDR3L Rev 10 i.MX 8M Nano & Derivatives A0 LPDDR4 Rev 9 i.MX 8M Nano & Derivatives A0 DDR4 Rev 12 i.MX 8M Nano & Derivatives A0 DDR3L Rev 6 i.MX 8M Plus & Derivatives A1 LPDDR4 Rev 9 i.MX 8M Plus & Derivatives A1 DDR4 Rev 9 * For the details about the updates, please refer to the Revision History tab of the respective RPA.    To modify the DRAM Frequency for a custom setting refer to iMX 8M Mini Register Programming Aid DRAM PLL setting    Related Resources Links: Config Tools for i.MX Applications Processors | NXP Semiconductors i.MX 8M Mini Register Programming Aid DRAM PLL setting  i.MX 8/8X Series DDR Tool Release  i.MX 6/7 DDR Stress test GUI Tool i.MX 8M Application Processor Related Resources i.MX8M (m850D) DDR Register Programming Aid (RPA)  i.MX8MMini (m845S) DDR Register Programming Aid (RPA)  i.MX8MNano (m815S) DDR Register Programming Aid (RPA) i.MX 8MPlus (m865S) DDR Register Programming Aids (RPA)   i.MX 8ULP DDR tools: i.MX Software and Development Tools | NXP Semiconductors Scroll down to “Other Resources --> Tools --> DDR Tools”  

This document is about enable iMX93 PWM and PWM led HW:   iMX93 11x11 EVK SW:   lf-6.6.3-1.0.0 PWM: TPM3 CH0, CH2            TPM4 CH2 Note: The i.MX PWM and           PWM led are already            enabled in lf-6.6.3-1.0.0  

Information about the transition from the NXP Demo Experience to GoPoint for i.MX Application Processors.

Overview This document explains how to use Pulse Width Modulation (PWM) on the iMX93 EVK Board. Attached to this post is a patch to enable this functionality, which can be integrated into either Yocto or a standalone kernel compilation.   This procedure was tested on iMX93 EVK A0 silicon version with BSP 6.1.22 version, this feature should work on A1 silicon version too but is not tested yet.   Kernel Configuration: To enable PWM support, modify the imx_v8_defconfig  file by adding the following line: CONFIG_PWM=y CONFIG_PWM_ADP5585=y CONFIG_PWM_CROS_EC=m CONFIG_PWM_FSL_FTM=m CONFIG_PWM_IMX27=y CONFIG_PWM_RPCHIP=y CONFIG_PWM_SL28CPLD=m + CONFIG_PWM_IMX_TPM=y​ # Add this line   Device Tree Modifications: You will need to add the following nodes to the device tree to configure the TPM (Timer/Pulse Width Modulation) controller:   + &tpm4 { + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_tpm4>; + status = "okay"; + }; ... + pinctrl_tpm4: tpm4grp { + fsl,pins = < + MX93_PAD_GPIO_IO05__TPM4_CH0 0x19e //EXP_GPIO_IO05 J1001 29 + >; + };​   Compiling and Flashing: After making the above changes, compile the kernel and device tree. Once the compilation is complete, flash the new image and device tree to the iMX93 EVK Board.  PWM Configuration on the Board After flashing, you can configure the PWM settings on the board. Open a terminal and execute the following commands: $ cd /sys/class/pwm/pwmchip1/ $ echo 0 >> export $ echo echo 2000000 >> pwm0/period # Set period to 2,000,000 ns (2 ms) $ echo echo 1000000 >> pwm0/duty_cycle # Set duty cycle to 1,000,000 ns (1 ms) $ echo 1 >> pwm0/enable   Validation To validate the PWM output signal, check pin 29 of connector J1001 on the iMX93 EVK Board.   Conclusion Following these steps should enable PWM functionality on your iMX93 EVK Board. If you encounter any issues, please refer to the documentation or reach out for assistance. Best Regards! Chavira

share more detailed steps how to bring up stereo capture of basler camera by imx8mp

Overview The purpose of this document is to provide a guide on how to enable UART 4 on i.MX8M Mini on Cortex A53. By default on i.MX-ATF is set on Cortex M4 Domain, i.MX-ATF helps ensure that i.MX processors boot securely. Reference: imx-atf. Requirements: Arm Toolchain: sudo apt-get install gcc-aarch64-linux-gnu 1. Build imx-boot image For a better reference how to build imx-boot image, go to Section 4.5.13 How to build imx-boot image by using imx-mkimage available on i.MX Linux User's Guide.   $ cd ~ $ git clone https://github.com/nxp-imx/uboot-imx -b lf_v2023.04 $ cd uboot-imx/ $ git checkout lf-6.6.23-2.0.0 $ make -j $(nproc --all) ARCH=arm CROSS_COMPILE=aarch64-linux-gnu- imx8mm_evk_defconfig $ export ARCH=arm64 $ cd ~ $ git clone https://github.com/nxp-imx/imx-mkimage.git $ cd imx-mkimage/ $ git checkout lf-6.6.23-2.0.0 $ cd ~ $ git clone https://github.com/nxp-imx/imx-atf.git $ cd imx-atf/ $ git checkout lf-6.6.23-2.0.0   The master domain for the UART4 is assigned to the Cortex M4, so, make the following changes to assign it to the A53 processor instead: diff --git a/plat/imx/imx8m/imx8mm/imx8mm_bl31_setup.c b/plat/imx/imx8m/imx8mm/imx8mm_bl31_setup.c index 179b6226f..b0427afff 100644 --- a/plat/imx/imx8m/imx8mm/imx8mm_bl31_setup.c +++ b/plat/imx/imx8m/imx8mm/imx8mm_bl31_setup.c @@ -114,10 +114,11 @@ static const struct imx_csu_cfg csu_cfg[] = { #else static const struct imx_rdc_cfg rdc[] = { /* Master domain assignment */ - RDC_MDAn(RDC_MDA_M4, DID1), + RDC_MDAn(RDC_MDA_A53, DID0), /* peripherals domain permission */ - RDC_PDAPn(RDC_PDAP_UART4, D1R | D1W), + RDC_PDAPn(RDC_PDAP_UART4, D0R | D0W), RDC_PDAPn(RDC_PDAP_UART2, D0R | D0W), RDC_PDAPn(RDC_PDAP_UART1, D0R | D0W),   After applying the changes, set your toolchain and then, compile with the following command: $ make PLAT=imx8mm bl31   In case you have the following error: Use this command to unset the flags and compile again: $ unset LDFLAGS   Then, copy the corresponding files to imx-mkimage/iMX8M. For more information, please check section 4.5.13 on i.MX Linux User's Guide. *NOTE: Some of this files are located on a link which you can access with the following command, for more information check the Release Notes, in this case for version 6.6.23-2.0.0 on Embedded Linux for i.MX Applications Processors. $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.24-fbe0a4c.bin $ chmod +x firmware-imx-8.24-fbe0a4c.bin $ ./firmware-imx-8.24-fbe0a4c.bin   Finally, copy flash.bin located on: imx-mkimage/iMX8M to a folder to flash your board as follows: You can download the uuu.exe from mfgtools and the .wic file from the prebuild images from: Embeded Linux for i.MX Applications Processors uuu.exe -b emmc_all flash.bin imx-image-full-imx8mmevk.wic   2. Change DTB to enable UART4 First, copy and rename the imx8mm-evk.dts to identify there is a change for enabling UART4: $ cd linux-imx $ cp arch/arm64/boot/dts/freescale/imx8mm-evk.dts arch/arm64/boot/dts/freescale/imx8mm-evk-uart4.dts $ vi arch/arm64/boot/dts/freescale/imx8mm-evk-uart4.dts And make the following changes: &ecspi2 { status = "disabled"; }; &uart4 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_uart4>; assigned-clocks = <&clk IMX8MM_CLK_UART4>; assigned-clock-parents = <&clk IMX8MM_SYS_PLL1_80M>; fsl,uart-has-rtscts; status = "okay"; }; &iomuxc { pinctrl_uart4: uart4grp { fsl,pins = < MX8MM_IOMUXC_ECSPI2_SCLK_UART4_DCE_RX 0x140 MX8MM_IOMUXC_ECSPI2_MOSI_UART4_DCE_TX 0x140 MX8MM_IOMUXC_ECSPI2_SS0_UART4_DCE_RTS_B 0x140 MX8MM_IOMUXC_ECSPI2_MISO_UART4_DCE_CTS_B 0x140 >; }; }   After applying the changes, set your toolchain and then, compile with the following commands: $ make imx_v8_defconfig $ make freescale/imx8mm-evk-uart4.dtb Finally, copy the DTB to your board, reboot it and change the DTB in the u-boot environment, boot your board and take a look to see if the UART4 is correctly enabled.    

Since U-Boot can read/write/update nodes inside the device tree blob before booting the kernel, the idea is to have a generic display node in the device tree which U-Boot will populate with the proper values. You can see in our source tree that all our device trees contain: fb_hdmi alias to setup HDMI configuration fb_lcd alias to setup LCD displays fb_lvds and t_lvds to setup LVDS1 display fb_lvds2 and t_lvds2 to setup LVDS2 display (when available) So U-Boot is now is charged to setup those nodes which will configure your display(s) easily. First of all it requires the U-Boot, Once you have a recent U-Boot, you can have a look at the supported display for your board by issuing: => fbpanel clock-frequency hactive vactive hback-porch hfront-porch vback-porch vfront-porch hsync-len vsync-len hdmi: 1280x720M@60:m24x1,50:74161969,1280,720,220,110,20,5,40,5 74161969 1280 720 220 110 20 5 40 5 hdmi: 1920x1080M@60:m24x1,50:148500148,1920,1080,148,88,36,4,44,5 148500148 1920 1080 148 88 36 4 44 5 ... Since the list is actually pretty long and not always easy to read, you can also filter by type of display (hdmi, lcd or lvds) => fbpanel lcd clock-frequency hactive vactive hback-porch hfront-porch vback-porch vfront-porch hsync-len vsync-len lcd: fusion7:m18x2,10:33264586,800,480,96,24,31,11,136,3 33264586 800 480 96 24 31 11 136 3 lcd: CLAA-WVGA:m18x2,48:27000027,800,480,40,60,10,10,20,10 27000027 800 480 40 60 10 10 20 10 ... => fbpanel lvds clock-frequency hactive vactive hback-porch hfront-porch vback-porch vfront-porch hsync-len vsync-len lvds: hannstar7:18x2,38:71108582,1280,800,80,48,15,2,32,6 71108582 1280 800 80 48 15 2 32 6 ... The above command just lists the available displays, when you want to set one, you need will to set the following variables: fb_hdmi controls HDMI display selection fb_lcd controls LCD display selection fb_lvds controls LVDS display selection fb_lvds2 controls LVDS2 display selection Also, when a display isn't used, you need to set it to off. Here is an example on how to setup the HDMI to display at 1080P and LVDS display to be the Hannstar 10' => setenv fb_lvds hannstar => setenv fb_hdmi 1920x1080M@60 => setenv fb_lcd off => saveenv Saving Environment to SPI Flash... SF: Detected SST25VF016B with page size 256 Bytes, erase size 4 KiB, total 2 MiB Erasing SPI flash...Writing to SPI flash...done => reset Once rebooted, you can have a look at the cmd_hdmi, cmd_lcd and cmd_lvds that U-Boot will have set => print cmd_hdmi cmd_hdmi=fdt set fb_hdmi status okay;fdt set fb_hdmi mode_str 1920x1080M@60; => print cmd_lvds cmd_lvds=fdt set fb_lvds status okay;fdt set fb_lvds interface_pix_fmt RGB666;fdt set ldb/lvds-channel@0 fsl,data-width ;fdt set ldb/lvds-channel@0 fsl,data-mapping spwg;fdt set t_lvds clock-frequency ;fdt set t_lvds hactive ;fdt set t_lvds vactive ;fdt set t_lvds hback-porch ;fdt set t_lvds hfront-porch ;fdt set t_lvds vback-porch ;fdt set t_lvds vfront-porch ;fdt set t_lvds hsync-len ;fdt set t_lvds vsync-len ; => print cmd_lcd cmd_lcd=fdt set fb_lcd status disabled Do not try to set those cmd_* variables yourself, they will be overwritten by U-Boot at bootup anyway. That's it, you should now be able to list, select and setup the displays the way you want. For another type of display, It depends on the type of display: LVDS: yes, since all the timings are inside the device tree node you can change them. Here is an example for our latest 7"1280x800 display, although only the latest U-Boot binary lists it, you can have it running by entering: => setenv fb_lvds tm070jdhg30:24:68152388,1280,800,5,63,2,39,1,1 => saveenv Note that it goes like this: setenv fb_xxx mode_str:connection-type:clk-frequency,hactive,vactive,hback-porch,hfront-porch,vback-porch,vfront-porch,hsync-len,vsync-len The connection-type is very important since it allows to specify: The data mapping: default is SPWG, need to add "j" to switch to JEIDA The split mode: for dual LVDS channels operations (for 1080P display for instance) need to add "s" The data width: can be 18 or 24 For instance, here is a fb_lvds setup for a dual channel JEIDA LVDS display with 24-bit witdth: => setenv fb_lvds 1080P60:js24:148500148,1920,1080,148,88,36,4,44,5 LCD: yes for U-Boot display, no for the kernel You can set the fb_lcd like it is done for LVDS above, however the timings will only be used to setup U-Boot, only the mode_str will be passed on to the kernel. This means that the kernel needs to know about the LCD beforehand. Here is an example for the ASIT500MA6F5D display: => setenv fb_lcd ASIT500MA6F5D:m24:32341861,800,480,88,40,32,13,48,3 => saveenv HDMI: yes (well more or less) Same as the LCD setting, only the mode_str is passed on to the kernel. The difference is that it can work out of the box on the kernel side if you ask for a standard resolution and standard refresh rate. For instance, setting fb_hdmi to 1920x1080M@30 will work automatically since the kernel is smart enough to recognize a known resolution (1080P) with a standard refresh rate (30fps).