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

We are pleased to announce that Config Tools for i.MX v25.06 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 – Support for i.MX 91 is added. – Synchronized with BSP Q2 release – Support for the i.MX 91 FRDM board is added. – Support for the i.MX 93 FRDM board is added. – Spectrum support for i.MX 95 and i.MX 943 is spread. – The Address mirroring option in the UI for all mscale devices with DDR3L and DDR4 is exposed. – DDR3L support for i.MX 8M and i.MX 8MM is added. – Linux support for code generation (beta) is added. • SerDes tool – i.MX 943 support (Beta) is added. • Clocks – Support for read-only element settings is added. – Filtering all settings of Initialization modules in the Details view is supported. • Peripherals – A wizard to export the Registers view data in the CSV format is supported. – Performance of the tool is improved. • An ability to export/import Expansion Boards and Expansion Headers is added.

Q: In mfgtool release 1.0.0 I, "Support only Cortex-A5 as primary boot core (Cortex-M4 boot is not supported on this release)." When will a version supporting M4 boot first be available? A: Mfg tool is based on it's counterpart, the ROM code. Rom code is for the A5 and not for the M4 as a matter of fact if you boot with the M4 and the device doesn't enumerate on the USB port at all then you know why and the MfgTool won't be able to do anything about it. Currently there no plans to provide a MfgTool version that supports boot from M4 core. Customers can modify the exisiting code to make it work with M4 as primary core. Booting from USB with the M4 core should work. The image that is booted must be for execution on M4 (thumb mode). MfgTool uses u-boot and a micro linux kernel to download images and program memories. This Linux can only run on the A5 core. To make it work with the M4 core as primary, it should be sufficient to add some code to the exisiting A5 images. Code will execute on M4 and start the A5 at the proper address as if it is booted from the A5.

Hypoxemia is a common clinical condition associated to several diseases that affect the respiratory system, including not only the lungs diseases, but also cardiac, neurological, neuromuscular and chest wall diseases. Its occurrence bring serious risks being essential its detection for appropriate treatment, and even to prevent the death of the patient. Hypoxemia is defined as the low saturation of oxygen carried by the blood. The most efficient way to determine the oxygen saturation is the gasometry, an invasive method (through the collection of blood) which is able to determine the gases present in the blood as well as its relative amount, as well as other data related to the blood. The Oximetry is a less effective method, but not least important, because of its practicality for not being an invasive method. Depending on the quality of the equipment, it can ensure very small variations with respect to the gasometry. In some cases, the constant monitoring of oxygen saturation is required. The portable oximeters are useful in such cases due to their ease of use. For monitoring oxygen saturation in the blood and also the heart rate, the machine suitable for this purpose is the Pulse Oximeter. Such equipment can be easily purchased at a low cost, but requires an assisted operation for each measurement, by the user or another person. This project proposed the development of a device capable of measuring blood oxygen saturation and heart rate. The data collected will be transmitted to a Smartphone, featuring an Android Application that displays the received data to the user and sends an automatic message to a health care center with the user's location in case of emergency. The project will also have sensors (accelerometers) to detect when the user has lost concience and fallen to the ground. This device will help to people with a history of health problems such as hypertension, hypoxia, risk of heart attack, among other diseases, giving them more autonomy, since in case of any health problems, somebody will be informed. The mobile monitoring of vital signals will detect when these signals vary significantly out of a safe range, and upon such occurrance a message is sent to pre-registered telephone numbers informing the user's location, and that he needs help help. The device will monitor the blood oxygen level and heart rate by measuring the change in the transparency of the blood through the presence of oxygen saturated hemoglobin is made. The measurement is taken by the emission of light at two wavelengths (red and infrared), where a sensor detects the intensity of light that is absorbed by hemoglobin, which depends on the degree of oxygen saturation. From the comparison between the received signals for each wavelength, it is possible to determine the degree of oxygen saturation in the blood. The meter is controlled by a microcontroller to be selected for this project. There will be a Bluetooth module connected to the microcontroller in order to establish the communication between the device and a paired Smartphone. An Android App will be developed to control the communicatin, display the user information sent by the device as well as send automatic voice messages to pre-registered telephones. The App will also reproduce additional messages played through the headphones to help the user in using the devices features, and also in case of emergency.

Test environment: i.MX8ULP EVK, SDK2.16 Some customer want to use LPUART2 in DSP domain on M33. This patch is based on lpuart_polling.   Hardware test point: If you send data from uart2, you will get such log from M33 console: reg = d2000000, 94000000 LPUART_WriteBlocking get readbuf = 73 get readbuf = 73  

Issue Description When running Android R10.4 on MX51 BBG, the system can not resume sometimes by following the test steps: 1) Enable CLAA-WVGA lcd panel - single display. 2) Play a video in Gallery. 3) Press power key to suspend the system. 4) Press power key to resume the system. 5) Do 3) and 4) continuously. Debug Details When adding the following debug information into vpu_resume function in file drivers/mxc/vpu/mxc_vpu.c, the system gets hang into while loop with the log "VPU Blocking 1**************": static int vpu_resume(struct platform_device *pdev) {         int i;                 WRITE_REG(BITVAL_PIC_RUN, BIT_INT_ENABLE);                 WRITE_REG(0x1, BIT_BUSY_FLAG);                 WRITE_REG(0x1, BIT_CODE_RUN);                 while (READ_REG(BIT_BUSY_FLAG)) {                           printk("VPU Blocking 1**************\r\n");                }; } Root Cause In some use cases,  VPU power gating didn't happen after vpu_suspend() returned successfully because some other devices refused to suspend or other reasons. So vpu_resume() ran FW init code when VPU was idle instead of power off, which could keep BIT_BUSY_FLAG always be 1. Solution In vpu_resume(), if VPU PC is not 0, which means VPU is still running, skip running FW init code. See attached patch based on R10.4.

Some customer want to measure DSM power and do some customize in their own board. We supply the the AN13917 to customer already. But some customer also have some questions about it , so here give more details and test for it for customer will more clearly understand and use it. 1 i.MX 93 power mode overview The i.MX 93 supports the following power modes: Run mode: In this mode, the Cortex-A55 CPU is active and running. Some portions can be shut off for power saving. Low-power run mode: This mode is defined as a Low-power run mode with all external power rails on. In this mode, all unnecessary power domains (MIX) can be off. The AONMIX and internal modules, such as OSC24M/PLL, are an exception in this mode. The Cortex CPU in AONMIX handles all the computing and data processing. Cortex-A55 is powered down and DRAM can be in self-refresh/retention mode. Idle mode: This mode is defined as one that a CPU can enter automatically when no threads are engaged, and no high-speed devices are in use. CPU can be put into a power-gated state, but with L3 data retained, DRAM, and bus clocks are reduced. Most of the internal logic is clock-gated; yet is still powered. In this mode, all the external power from PMIC remains the same, and most IPs remain in their state. Therefore, the interrupt response in this mode is quick compared to the Run mode. Suspend mode: This mode is defined as the most power-saving mode since it shuts off all the clocks and all the unnecessary power supplies. In this mode, the Cortex-A55 CPU is fully power gated, all internal digital logic, and the analog circuits that can be powered down are off, and all PHYs are power gated. VDD_SOC(and related digital supply) voltage is reduced to the "Suspend mode" voltage. Compared to Idle, this mode takes a longer time to exit, but it also uses far less energy. BBSM mode: This mode is also called RTC mode. In this mode, to keep RTC and BBSM logic alive, only the power for the BBSM domain remains on. Off mode: In this mode, all power rails are off. 2 Measure the power consumption of the system in the DSM( Deep Sleep Mode) The use case is based on the Suspend mode, which implies the following: CA55 cluster is OFF • MEDIAMIX is OFF • NICMIX is OFF • WAKEUPMIX is OFF • PLL is OFF • 24 M OSC is OFF PMIC is in STBY mode Download the demo images from website: Download the AN13917SW.zip file, upzip it. Copy the uuu and imx93-11x11-evk-dsm.dtb to demo images path. Download the images to board: .\uuu.exe -b emmc_all .\ imx-boot-imx93-11x11-lpddr4x-evk-sd.bin-flash_singleboot  .\imx-image-full-imx93evk.wic To measure the power consumption of the system in the DSM, the steps are as follows: Boot the Linux image with imx93-11x11-evk-DSM.dtb. System boot up with the default dtb, when system boot up change it to the imx93-11x11-evk-DSM.dtb, using the following commends: setenv fdtfile imx93-11x11-evk-dsm.dtb saveenv boot To put the system into the Suspend (Deep sleep) mode, run the following command: echo mem > /sys/power/state Measure the power and record the results. About the BCU Tool: BCU (Board Remote Control Utilities):BCU is a software specially designed to control boards/platforms that support remote control. It provides functions such as on/off key operation, board reset, setting boot mode, controlling GPIO, and power measurement through the debug cable. ------->Remote Control function: $ sudo ./bcu reset sd [-board=xxx] version bcu_1.0.158-0-gdb0a8e5 Auto recognized the board: imx8dxlevk set reset high successfully set onoff high successfully set ft_reset high successfully ENABLE remote control set sd_pwr high successfully set sd_wp high successfully set sd_cd high successfully set boot mode successfully set bootmode_sel low successfully Set ALL sense resistances to smaller ones rebooting... reset successfully done -------->Power measurement function: $ sudo ./bcu monitor -hz=1 [-board=xxx] Here for the power measurement function support the boards have power measurement function. This is the example for the power measurement for the i.MX93 EVK board: 1\Download the BCU tool Releases · nxp-imx/bcu Download the bcu_1.1.100 to Windows 2\Connect the i.MX93 EVK board to Windows PC 3\Open the teminal in the Windows PC C:\Users \Desktop>bcu.exe monitor -board=imx93evk11b1 -hz=1 Use the bcu.exe monitor -board=imx93evk11b1 -hz=1 Make sure the board version is proper, current board is B1 version, so the board name is imx93evk11b1. 4\Run the command in the PC : For others mode test can refer to the BCU.pdf file: https://github.com/nxp-imx/bcu/releases/download/bcu_1.1.100/BCU.pdf Note: To make sure the board version are proper with the related command: bcu.exe monitor -board=imx93evk11b1 -hz=1 For the i.MX93 SOM B2 version Board can use the above command. If the board version is old, such as use the i.MX93 SOM B, here you need to use the command: bcu.exe monitor -board=imx93evk11 If using the bcu.exe monitor -board=imx93evk11b1 the test result are not for this board, here can use the ./bcu eeprom -w -board=imx93evk11 to write the eeprom for the imx93evk11. Using the bcu eeprom -r -board=imx93evk11 see the present status. If we met the problem as bellow we need to check and write to the eeprom again. Measure the power in the DSM mode on the i.MX93 board with SOMB2(board name with the i.mx93evk11b1): old EVK imx93evk11 use a 20m Ohms sensing resistor new EVK imx93evk11b1 use a 5m Ohms sensing resistor For the the i.MX93 board with SOM B Measure the power in the DSM mode on the i.MX93 board with SOMB2 result, use the small and larger range test: Measure the power in the DSM mode on the i.MX93 board with SOMB result: Using the command bcu.exe monitor -board=imx93evk11 -hz=1 3 Questions from customer a.The diff/patch between imx93-11x11-evk.dts and imx93-11x11-evk-dsm.dts If customer use the Linux kernel version: L6.1.55 version BSP, they need to use the imx93-11x11-evk-dsm.dtb we supply. And if using the newer than it and newest BSP in our website, they do not need to change the dtb to the and imx93-11x11-evk-dsm.dtb, just using the imx93-11x11-evk.dts will be OK, as for the Atf  also add the has_wakeup_irq = true;   And in the default imx93-11x11-evk.dts already support the  linux-imx/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts at lf-6.12.y · nxp-imx/linux-imx · GitHub   So customer and directly use on their products. b. NXP i.MX93 EVK DSM power measurement, the GROUP_SOC_FULL  are some difference from our AN. As different chips may show slight differences in static power consumption(SS TT FF) due to process corner variations.  

Currently, we meet an issue that some jpeg pictures can't be displayed on  imx53 platform by command "gst-launch filesrc location=JPEGFILE ! jpegdec ! freeze ! mfw_isink", the system will meet application crash. So we did investigation on this, found imx6 aslo has such issue.   We found that the issue happen on specific jpeg pictures, the width & height is not 8 pixels alignment.   After track the code ,  found that the jpeg decoder send the width and height to isink plugin, also it send a outsize calculate by the width and height with algorithm that will do 2 pixels,4 pixles,8pixles alignment(I420_SIZE (width, height)). The isink use a different algorithm to calculate the decoder buffer, this size is always smaller than the size pass down by the jpeg decoder , in later memory copy, the code copy a large memory to smaller memory, it's out of boundery, corrupt the memoryand cause the application fail.   So we make a little change, to malloc the larger size to avoid the out of boundry. Original Attachment has been moved to: fix-8pixels-unalignment-jpeg-display-crash.patch.zip

We are pleased to announce that Config Tools for i.MX v16.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...) • Clocks – Disabling enabled clock outputs that have settings with shared bit-fields after reopening the configuration is fixed. – Clock slices with multiple outputs are supported. • TEE – An incorrect number of the MPU region attributes shown for the configuration of RT1180 is fixed. – An incorrect domain visibility and tab names when DAC is disabled on RT1180 is fixed.

Add SSI_ASRC_P2P support for imx6 based on Kernel 3.0.35.

Question: Two boards are used and practically identical - one using the i.MX6Solo, the other is using a Dual. The sw settings in both cases are identical (except IOMUX addresses). On the i.MX6Solo they do not see any packet loss, on the i.MX6Dual they do. I recommended modifying the MTU size, but this also did not help. So here my two questions: 1)      is there still some hw difference between the Ethernet block on the Solo and the Dual/Quad? 2)      They run the AHB at only 100MHz. Could that be a problem? If not, why do the two chips behave so differently? To increase the AHB clock to 133 MHz.appears to solve the packet corruption issue. Is the 100 MHz AHB clock really the root cause. Answer: The DualLite/Solo and SoloLite contain different ethernet controllers. The DL/S has a 1000M controller which requires the AHB bus to be greater than 125MHz, while the SL has a 100M controller. As the question was about the Solo and the Dual and both use the Gigabit Ethernet block I assume that both will require a minimum AHB clock of 125MHz.

Question: The description of the IOMUXC_GPR2 register is wrong. It contains exactly the same description as the LDB_CTRL register. The bits in the LDB_CTRL register work as advertised opposed to the GPR2 register. Answer: This is intentional. The LDB_CTRL description in the RM says "The register is implemented in the IOMUX Controller block (IOMUXC), as the register IOMUXC_GPR2.". And you will notice the two registers have the same address.

To get the FSL amrdecoder building and running on imx53 in 11.09 BSP: TIP: During debug for creation of these patches -> On the target, I had to make sure I had all the amr decoder libraries present, or it just wouldn't work. I narrowed those down by deleting "rm /root/.gstreamer-0.10/registry.arm.bin" and rerunning gst-inspect to rescan the plugins. With GST_DEBUG=3 I could see what libraries were missing and copied them over. But once everything was in place, it just worked. gst-launch playbin2 uri=file:////media/sd/media_file_with_amr_audio_encoding.3gp Attached are the new .spec files and patch files to get this to work. Regards, Randy

Q: To minimize i.MX6DL power consumption at stop mode, but needs i.MX6DL to wake-up by USB resume signal from Host PC. Can LDO_2P5(VDDHIGH_CAP) be powered off at stop mode in order to resume i.MX6DL by a USB resume signal that Host PC sends to i.MX6DL USBOTG(us as device mode only)? In other words, can USB OTG detect resume signal from Host PC and generate wakeup interrupt during stop mode with following LDO condition? -          LDO_USB is enabled and powered by USB_OTG_VBUS. -          LDO_2P5 is disabled during stop mode. -          LDO_1P1 is enabled during stop mode. The system uses LPDDR2, hence LDO_2P5 can be powered off at stop mode(I know this is not allowed for DDR3 as DDR IO need 2P5 as pre-driver). Actually tested on SDP, the system can not be resumed without LDO_2P5 as DDR IO need 2P5 for DDR3. A: Please note that disabling the LDO_2P5 supply, you are also disabling the DRAM, as the DRAM pre-drivers are powered by this supply(!). SDCKE is pulled down on the board, and it ensures that the DRAM is in proper state during DSM without LDO_2P5 power. we recommend to keep LDO_2P5 on at any mode(include DSM mode). ldo_2p5 is also one of power for USB phy.   4.3.2.2 LDO_2P5 The LDO_2P5 module implements a programmable linear-regulator function from VDD_HIGH_IN. The LDO_2P5 supplies the SATA Phy, USB Phy, LVDS Phy,   Actually I have tested on SDP, but we cannot resume the system without LDO_2P5 as DDR IO need 2P5 for DDR3.

This blog enables support of Qemu emulation for iMX8MM EVK.  Imagine not having the hardware but still you want to test the software. Qemu gives you exactly that. 1. Booting uboot, linux and user-space application even when you do not possess a real hardware. 2. Early firmware development when the silicon doesn’t yet exist. 3. Linux driver development, debugging and testing.

Q:Is there an issue using odd DIV_SELECT values? When setting the CPU clock (maybe others also) in uboot, the code will only use even valuesfor the DIV_SELECT field. There is nothing in the Reference Manual or Errata that indicates only even values can be used for this field. There were 2 SR's that had conflicting answers and we are trying to determine what can be used. The CPU freq setting trying to be achieved is 996MHz. With a 24MHz source, you need 24MHz x 41.5 = 996MHz. Since the DIV_SELECT is x2, a value of 83 would be needed. A: Below is the DIV_SELECT description of ARM PLL, since the Fin is 24MHz, so there is no odd issue of DVI_SELECT, as 24 / 2 = 12MHz. Such as for 996M, this value is 83, that is fine. "This field controls the pll loop divider. Valid range for divider value: 54-108. Fout = Fin * div_select/2.0." This document was generated from the following discussion: mx6Q PLL Setting

  This article is an example for users to change the DDR clock on i.MX6ULL board Environment: Hardware : i.MX6ULL EVK board Concept of MMDC controller clock source on i.MX6ull Consult Chapter 18 Clock Controller Module(CCM) in the I.MX 6ull reference manual. The MMDC clock source is shown in Figure 23.3.3.1:   Figure 23.3.3.1 MMDC Clock Source Figure 23.3.3.1 shows the clock source path diagram of MMDC, which is mainly divided into three parts. 1. CBCMR[PRE_PERIPH2_CLK_SEL] : The pre_periph2 clock selector, which is the pre-selector of periph2_clkd, is controlled by the PRE_PERIPH2_CLK_SEL bit (bit22:21) of the CBCMR register. 2. CBCDR[PERIPH2_CLK_SEL] : periph2_clk clock selector, controlled by the PERIPH2_CLK_SEL bit (bit26) of the CBCDR register,When it is 0, pll2_main_clk is selected as the clock source of periph2_clk. When it is 1, periph2_clk2_clk is selected as the clock source of periph2_clk. 3. CBCDR[FABRIC_MMDC_PODF] : It is a frequency divider. The frequency division value is set by the FABRIC_MMDC_PODF bit (bit5:3) of the CBCDR register. It can be set to 0~7, corresponding to 1~8 frequency divisions respectively. To configure the clock source of the MMDC to 396MHz, it must be set to 1 here, so FABRIC_MMDC_PODF=0. The above is the clock source setting of MMDC. Implementation Step 1 : git clone the uboot code from NXP github web $ git clone https://github.com/nxp-imx/uboot-imx.git Step 2 : Modify the different frequencies of DDR by modifying the following files : uboot-imx/board/freescale/mx6ullevk/imximage.cfg As default BSP code, our DDR run frequency is 400MHz (Actually, it's 396MHz), If you want DDR to boot at 132MHz, we need to configurate the CCM_CBCDR[FABRIC_MMDC_PODF] bit,  from this bit content, we need to set it to 010. The frequency division value is 3 based on 396MHz   Change code as following: DATA 4 0x020c4014 0x00018910, Add this code in imximage.cfg file. Step 3 : Re-compile the uboot and flash the uboot to the board. Result Now, We can see that DDR is running at successfully at 132MHz. Before modification:   After modification:      

Test environment: i.MX8ULP EVK, SDK2.16 Some customer want to use LPUART2 in DSP domain on M33 core. This patch is based on lpuart_edma example.   Hardware test point:   You will get such log from LPUART2 if we enter 3 on keyboard LPUART EDMA example Send back received data Echo every 8 characters 33333333   Modify M33 debug console from LPUART1 to LPUART2 is similiar.

Question: How to enable touch functions on LVDS1/SabreAI base board? what should be soldered in order to connect the signals to i2c what to add in the Linux kernel (board-mx6q_sabreauto.c) BTW.: Why did we leave these disconnected? Is there any conflict on i2c? Answer: You can mount R305 and R306 to support touch on LVDS1, no code modification was needed. The only limitation is that the two LVDS's touch can't be connected to same I2C port, because they are using the same I2C address. Question: How is this working because the touch interrupt signal from LVDS1 called LCD1_TOUCH_INT_B is connected to pin21 on J44 on base board which is left floating (TP1) on CPU card P1A connector? Are both LVDS needed to work in the same time. Answer: That's the problem, the LVDS1 touch interrupt pin hasn't been connected to IMX6 CPU. Maybe you can use the SabreSD board, the two touch are ready on that board.

The refine to TV mode of R10.3.1 causes dual video function fail. The attached patch recovers dual video function. Attached dual_video.patch only work for RGB output (HDMI support). For legacy TVout (YUV output), the extra patch is necessary, see the attached "legacy_tvout.zip". Refer to Dual video with single UI on i.MX53 SMD with Android R10.4  for setup.