We are pleased to announce that Config Tools for i.MX v15.1 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...)   Version 15.1 • On MacOS aarch64, the missing Overview is fixed. • TEE – Pin tables now only contain items for specific configuration (mask/security/interrupts).

Question: When working with v1.6.0.55 using the standard profile for i.MX35 the tool fails most of the time when transferring the target root file system, on v1.6.0.42 it works just fine. The tags on the internal git don’t clearly mention a tool version, but a BSP. Wwhat are the differences between v1.6.0.55 and v1.6.0.42? Or to which tag(or commit) they correspond on git? Answer: 1.6.042 commit by looking at "Apps/MfgTool.exe/docs/changelog.txt": 1ca2a16df736ac51979a67423fef6a09bed6b7e2 And 1.6.055: "06a4f9190e34297b7273fc4bb4a92737e5bc837f"

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-341473 

This document explains how to create a DS-5 project to compile and debug the SDK and OBDS for iMX6 and iMX28 respectively. Attached you can find the .ds file for the iMX28 needed to debug in DS-5.

imx8mm platform on 4.14.78/98 GA Android  LCD MIPI panel or HDMI display may appear some strange color stride .  This is  one patch for this issue. 

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-345751 

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-341996 

Q: ”We noticed that the specified risetime of this signal is max 5nS, while the Sable board schematic shows it driven from open collector/drain using only the 100k haulup provided in the chip. This will have risetimes of 10‘s (if not 100‘s!) of ns. The worrying thing is that the latest datasheet update specifically clarifies this rise time spec, so presumably it‘s considered important. Which is right? If the rise time spec needs to be met, we need a small haul up resistor or an active drive. In that case what rail should be used to haul/drive POR_B high?” It appears to be correct, and what is interesting I checked the PFUZE timing in the datasheet ”tr4 Rise time of RESETBMCU - 0.2 ms” Device: i.MX6Q OS: Linux Dev Board: i.MX6Q SDB A: The 5ns rise/fall time requirement does not apply to i.MX6. This was probably carried over from the i.MX53 where it was required. This will be removed from the datasheet but it will likely not be until the September time frame. We're not doing an update to any of the electrical parameters of the datasheet right now.

Documents Imx53-fastboot-example i.MX53 Multimedia Applications Processors I.MX53 QSB Board Get Started IMX53 QSB enable WIFI android I.MX53 QSB Ubuntu Dual Display i.MX53 Quick Start Board IMX53 SABRE AI i.MX53 Start-R Lab Exercise - Prof. Massimo Violante Politecnico of Torino i.MX53 Start-R Lab Exercise - Developing a loadable kernel module to manage GPIOs in i.MX53QSB ConnectCore® i.MX53 / Wi-i.MX53 by Digi International NOVPEK i.MX53 by NovTech

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-343521 

Computer On Module • Processor Freescale i.MX287, 454 MHz • RAM 128MB DDR2-400 SDRAM • ROM 128MB NAND Flash • Power supply Single 3.1V to 5.5V • Size 40mmX35mm • Temp.-Range -40°C..85°C Key Features • Two 10/100Mbps Ethernet ports with IEEE1588 support • Two High-Speed USB 2.0 ports • One colour LCD controller • Two CAN interfaces • 4 wire Touchscreen interface • Several peripheral interfaces: UART, SD-CARD, I2C, PWM, Serial Audio, SPI • Power management optimized for long battery life • 3.3V I/O OS Support • Windows Embedded CE 6.0 • Linux 2.6.35 Application：Building control, factory automation, printers and security panels, HMI, industrial control media gateways / accessories, portable medical devices, energy-saving Energy Gateway / Meter For more information, please see Attachment We can provide a complete solution

Dear,   We want to start application program from bootloader, we have below questions: We we use I.MX6UL bootrom start BootLoader， we need use mkimage.sh, compile and generator bin file, then we convert to executable file. If we need use Bootloader run application program,whether application image also need convert by mkimage.sh?  The file which convert by mkimage.sh is compressed file. we do not know its format, how about its start address, how to realize the the address jump, do you have example? Thanks.  

Hello Android users Otto has posted on the Element14 community some clear tutorial (accessible following the link below) to build Android from source. RIoTboard: Building Android from Source | element14 I recommend you to start following those steps to properly setup the Android tools. Happy Source Programming Greg

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.

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.

Symptoms   On i.MX8MP, when inputting a 80% duty, 0.4V-1.8V, 3KHz square wave, we observed that the system may hang. We also tested i.MX8MN and i.MX8MM and observed the same phenomenon. In i.MX8MN RM, there's a note in GPC chapter:     We believe that the issue described in this note exists not only in the iMX8MN, but also in the iMX8MP and iMX8MM. Meanwhile, there is not only a problem with power down in this issue, but also a problem with wait mode. Diagnosis   In debugging, we find that avoiding accessing LPCR_A53_AD register in imx_set_cluster_powerdown can fix the issue. So we think that due to frequently power up/down of cores, cores have chances failed to power up. When the IRQ behavior become more complex, because the IRQ is an async event, it will come in any time. if the wait mode is enabled, in some conner case, the GPC internal LPM mode state machine will run into problem, then lead to system failure. Solution   1. A workaround patch that bypass the wait mode setting during the cpuidle.. See the patch attached. 2. Will add the Note about "SCU power down should not be enabled in wait mode" to i.MX8MP and i.MX8MM RM. 3. Will try to identify this issue into errta document, ticket TKT0632147.

We have validated Toshiba Smart NAND in our i.MX6SX platform, and boot successfully. The results are as below: 1. chip part number: THGBR2G5D1JTA00,  page_size: 16k+64  pages_per_block: 256 2. test platform: i.MX6SX Some information to take care of: 1. The pin assignment of smart nand is different from common raw nand, that is, Nand pin1 must connect to Vcc, pin2 connects to Vss, pin23 connects to VssQ, pin24 connects to VccQ, pin38 connects to VccQ 2. The ECC layout of FCB page itself must be set according to the i.MX6SX RM, otherwise FCB can't be read correctly. 3. EccBlock0EccType and EccBlockNEccType in FCB must be set as 0, and raw data can be put in DBBT and firmware without any ECC check codes.

                For the SPI NOR booting on fuse steps. 1.      Please boot your PCB on uboot and type below command for fuse boot setting. MX6Q SABRESD-MFG U-Boot > imxotp blow --force 5 0x0a000030 MX6Q SABRESD-MFG U-Boot > imxotp read 5 Reading fuse at index: 0x5 Fuse at (index: 0x5) value: 0xA000030 MX6Q SABRESD-MFG U-Boot > imxotp read 6 Reading fuse at index: 0x6 Fuse at (index: 0x6) value: 0x0 MX6Q SABRESD-MFG U-Boot > imxotp blow --force 6 0x10 Current fuse at (index: 0x6) value: 0x0 Blowing fuse at index: 0x6, value: 0x10 Reloading shadow registers... Operation succeeded fuse at (index: 0x6) value: 0x10 MX6Q SABRESD-MFG U-Boot > imxotp read 6 Reading fuse at index: 0x6 Fuse at (index: 0x6) value: 0x10 MX6Q SABRESD-MFG U-Boot > 2.      Set the boot mode for 00 as Boot from fuses 3.      You could see the SPI clock on scope after re power on.

Summary of the Issue: We have had customers reporting failure to run MC and SC production parts at 1GHz or higher frequencies. The signature of the fail is that the system will hang once it tries to ramp from the boot frequency of 800MHz to 1GHz or higher. The root cause was tracked to the setting of the LDO_VOLT_CHANGE_EN fuse in production parts. The LDO_VOLT_CHANGE_EN fuse sets the LDO boot voltage to either 1.15V (indicated by a fuse setting of “1”) or 1.1V  (indicated by a fuse setting of “0”). In production parts the fuse is set to “1”, i.e. 1.15V, since this is the optimal setting based on characterization data. On pre-production units the LDO voltage was set to the lower setting of 1.1V (i.e. fuse set to “0”). The reason this is a problem with MC/SC parts is because the fuse is read by the ROM during boot and overwrites the LDO ramp rate bits in the PMU_MISC2 register based on the setting of the fuse. When the LDO_VOLT_CHANG_EN fuse is set to “1” then the LDO ramp up time to spec voltage is set (in PMU_MISC2) to 500uS instead of the 50uS assumed by the CPUFreq driver. This will cause the system to hang when transitioning from the boot frequency to a higher frequency/voltage point since the required voltage to support the higher frequency is not yet present. In real terms, customers who have production i.MX 6Quad/6Dual/6DualLite and 6 Solo parts have seen failures to ramp their products to 1GHz or higher frequencies. This is completely fixed by a software patch that corrects the LDO ramp setting in the PMU_MISC_2 register by setting it back to the fastest ramp time. Note that the LDO_VOLT_CHANGE_EN fuse is not in the reference manual since it is not a customer visible fuse. It is programmed and locked at final test. This is a mandatory fix for all customers. Affected Parts: i.MX 6Quad – all SC and MC parts, consumer and automotive. Industrial MC parts not yet shipping. i.MX 6Dual – all SC and MC parts, consumer and automotive. Industrial MC parts not yet shipping. i.MX 6DualLite – all MC parts consumer parts. Automotive and industrial MC parts not yet shipping. i.MX 6Solo – all MC consumer parts. Automotive and industrial MC parts not yet shipping. Patch Availability and Location: Patches exist for both Linux and Android. They are available on freescale.com. See below for more details. i.MX 6Quad – www.freescale.com/imx6q i.MX 6Dual – www.freescale.com/imx6d i.MX 6DualLite – www.freescale.com/imx6dl  i.MX 6Solo – www.freescale.com/imx6s Select the “Software and Tools” tab and then expand the section “Updates and Patches”.  The relevant patches are: Linux – L3.0.35_1.1.1_LDO_PATCH (i.MX 6Quad/6Dual) Linux – L3.0.35_3.0.3_LDO_PATCH (i.MX 6DualLite/6Solo) Android – IMX6_R13.4103_ANDROID_LDO_PATCH (i.MX 6Quad/6Dual/6DualLite/6Solo) Communication Roll-out: i.MX FAE’s: done (via maillist). Will post copy of this email to i.MX support space by end of day 1 st March. i.MX DFAE’s: 8 th March. Customer notification: 8 th March. i.MX community: 8 th March (to coincide with customer notification). We are also working on an engineering bulletin that describes the change for customers who are not using our provided Linux and Android BSP’s. Target date: TBD. But goal is to make this available on/around mid-March. Best regards, Amanda and Kyle This document was generated from the following discussion: i.MX 6 Series LDO Ramp Issue: Linux and Android Patches Now Available

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-345322