I was trying to implement an E-Ink solution using IMX7D. Unfortunately I only had a IMXEBOOKDC3 available, not the DC4 shown on the IMX7D E-Ink tutorials. After a couple of tries I found the right way of connecting the expansion board and the the definition of the arguments on U-boot to make the IMX7D and DC3 work together.  I logged these considerations on the blog post below: http://bit.ly/IMX7D_IMXEBOOKDC3   Andres

MX6X_Uboot_V1-20130910.doc: 3.0.35: 3.0.35

Dear All,       Our board is designed based on both EVK and HEG (Adeneo Embedded Home Energy Gateway), the ENET_FEC_RESET_B on EVK is replaced by LCD_D11 as it on HEG. We have re-config all pins based on i.mx28 BSP and successfully built by ltib. However, eth0 is not working due to "PHY is not found"! and we are still trying to figure it out.       The changes we apply on the BSP are(in mx28evk_pins.c): in static struct pin_desc mx28evk_fixed_pins[]:       the definition of LCD_D11 change to { .name = "LCD_D11", .id = PINID_LCD_D11, /* PHY reset pin*/ .fun = PIN_GPIO,      .voltage    = PAD_3_3V,      .strength = PAD_8MA,      .output     = 0, },      and replace all "PINID_ENET0_RX_CLK" in mx28evk_pins.c by "PINID_LCD_D11"      To prevent any possible interrupt, we also disable all LCD pins in both mx28_pins.h and mx28evk_pins.c since we don't have LCD.      Any comment/suggestion is highly appreciate! BR, TF

give an example for bring up the imx8mq DP/eDP board based on nxp SW

Issue: kernel panic when repeating plug/unplug USB device(e.g. USB flash disk) in Linux 4.1.15 The issue is in kernel BLOCK DEVICE, this is not a hardware related issue(happens to all devices running L4.1.15 or L4.4.x), please refer to following link on kernel.org for more details and fixes: blockdev kernel regression (bugzilla 173031) - Patchwork 

[中文翻译版] 见附件   原文链接： 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.

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.

SW : uboot-imx lf_v2025.04 HW : i.MX 8MP EVK board, Oscilloscope   1. Introduction This guide explains the concept of DDR clock spread spectrum on the i.MX 8MP EVK platform. Note that the official NXP BSP does not enable this feature by default. Additionally, this guide provides an example code patch and verification steps to enable the LPDDR4 clock spread spectrum feature on the NXP i.MX 8MP EVK board.   2. What is Spread Spectrum? Spread Spectrum (SS) is a technique used to reduce electromagnetic interference (EMI) by slightly modulating the clock frequency around its nominal value. Instead of operating at a fixed frequency (e.g., 800 MHz), the clock signal is varied within a small range (e.g., ±0.5%). This modulation spreads the energy of the clock signal over a wider frequency band, reducing the peak energy at any single frequency. In other words, SS does not change the average clock speed significantly, but it helps to distribute the spectral energy, making the system less likely to violate EMI regulations.   3. Why Enable Spread Spectrum on DRAM Clock? Enabling Spread Spectrum on the DRAM clock helps reduce electromagnetic interference (EMI) by slightly modulating the clock frequency, lowering peak emissions and making it easier to meet regulatory standards such as FCC and CE. This approach improves system reliability by minimizing interference with other components, offers a cost-effective alternative to hardware changes like shielding or PCB redesign, and is widely adopted in high-speed interfaces such as DDR, PCIe, and SATA to ensure compliance without additional hardware complexity.   4. Related registers CCM_ANALOG_DRAM_PLL_SSCG_CTRL                             Note :  PLL_MFREQ_CTL[19 : 12] : Value of modulation frequency control The larger the mfr value, the lower the MF value (the slower the modulation); the smaller the mfr value, the higher the MF value. MF : The frequency of spread spectrum modulation is the speed at which the triangular/sawtooth modulated wave travels back and forth once per second, measured in Hz (commonly in the tens of kHz range). The speed of the spread spectrum "jitter" is determined. Usually, around 20–50 kHz is chosen to make the energy "swipe evenly" within the bandwidth of the EMI test receiver, thereby reducing the peak radiation at a certain frequency point. PLL_MRAT_CTL[9 : 4] : Value of modulation rate control The larger mrr is, the larger MR is (the wider the range); similarly, MR is also directly proportional to mfr and inversely proportional to m. MR : Peak-to-peak percentage of spread spectrum (the percentage of the total range of the clock frequency swinging around the center value). For example, MR = 0.5% means that the frequency swings around the center value by a total of 0.5% (if it is center-spread spectrum, it is usually ±0.25%).The MR determines the depth (width) of the spread spectrum. The larger the MR, the wider the spectral energy distribution and the lower the peak value, but it comes at the cost of jitter/timing margin (timing should be carefully selected for DDR, SerDes, etc.). 5. About Uboot code patch. Please refer the attachment patch file. At high DRAM frequency, Enable SS may cause not stable problem. So, in this case, I will choose 2400Mbps data clock run the test. Firstly, we should make sure that our code include the 2400Mbps PLL setting. DRAM data speed is 2400Mbps, the DRAM clock is 1200MHz. So the DDRC PLL clock should set up with 600MHz. For example, refer the below code. static struct imx_int_pll_rate_table imx8mm_fracpll_tbl[] = {     PLL_1443X_RATE(1000000000U, 250, 3, 1, 0),     PLL_1443X_RATE(933000000U, 311, 4, 1, 0),     PLL_1443X_RATE(900000000U, 300, 2, 2, 0),     PLL_1443X_RATE(800000000U, 200, 3, 1, 0),     PLL_1443X_RATE(750000000U, 250, 2, 2, 0),     PLL_1443X_RATE(650000000U, 325, 3, 2, 0),     PLL_1443X_RATE(600000000U, 300, 3, 2, 0), // 2400Mbps     PLL_1443X_RATE(594000000U, 99, 1, 2, 0),     PLL_1443X_RATE(400000000U, 400, 3, 3, 0),     PLL_1443X_RATE(266000000U, 266, 3, 3, 0),     PLL_1443X_RATE(167000000U, 334, 3, 4, 0),     PLL_1443X_RATE(100000000U, 200, 3, 4, 0), }; PLL output calculator formula is : PLL_out = 24MHz*mdiv/pdiv/(2^sdiv) So, 2400MHz * 300 / 3 / 2^2 = 600MHz   6. Test result Non Enable SS Enable SS with 1% MR and Down spread Enable SS with 2% MR and Down spread Enable SS with 2% MR and Center spread  

  This article shows how to use the i.MX6DL/Q to transcode and stream videos on 1080i/p @ 24fps and 720p @ 30fps. For this test, we used one i.MX6DL as server and an i.MX6DL and i.MX6Q as clients. The video is streamed by the server, playing the sound at the same time, while the clients show the video in the HDMI output, as the image below:     This test depends on some GStreamer plugins. To check that the right GStreamer plugins are installed type the following commands: $ gst-inspect-1.0 | grep h264 To return all the H.264 related plugins, or: $ gst-inspect-1.0 decodebin To check directly the command. To connect more than one board to the minicom, open it with the command: $ sudo minicom –s This way, you open the configuration menu. Enter in the “Serial port setup” option and press “A” to set or change the PORTNUMBER, in “ttyUSB$PORTNUMBER”. To set the HDMI output, run the commands below from the U-Boot prompt: => setenv mmcargs 'setenv bootargs console=ttymxc0,115200 root=/dev/mmcblk2p2 rootwait rw video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24 consoleblank=0' => saveenv Be sure that the IPs are correctly setted: SERVER: => ifconfig eth0 $SERVERIP CLIENTS: => ifconfig eth0 $CLIENTSIP Streaming transcoded video only SERVER: => gst-launch-1.0 filesrc location=/home/root/bbb_720p.mp4 ! decodebin ! queue max-size-buffers=0 ! vpuenc_h264 gop-size=2 bitrate=20000 ! queue max-size-buffers=0 ! rtph264pay config-interval=2 ! queue max-size-buffers=0 ! gdppay ! tcpserversink blocksize=512000 host=$SERVERIP$ port=8554 CLIENTS: => gst-launch-1.0 tcpclientsrc host=$SERVERIP$ port=8554 ! gdpdepay ! queue max-size-buffers=0 ! 'application/x-rtp, media=(string)video, clock10-rate=(int)90000, payload=(int)96' ! queue max-size-buffers=0 ! rtpjitterbuffer latency=100 ! queue max-size-buffers=0 ! rtph264depay ! queue max-size-buffers=0 ! decodebin ! autovideosink sync=false Streaming transcoded video + audio SERVER: => gst-launch-1.0 filesrc location=/home/root/bbb_720p.mp4 ! decodebin name=demux demux. ! queue max-size-buffers=0 ! vpuenc_h264 gop-size=2 bitrate=20000 ! queue max-size-buffers=0 ! rtph264pay config-interval=2 ! queue max-size-buffers=0 ! gdppay ! tcpserversink blocksize=512000 host=$SERVERIP$ port=8554 demux. ! alsasink CLIENTS: => gst-launch-1.0 tcpclientsrc host=$SERVERIP$ port=8554 ! gdpdepay ! queue max-size-buffers=0 ! 'application/x-rtp, media=(string)video, clock10-rate=(int)90000, encoding-name=(string)H264' ! queue max-size-buffers=0 ! rtpjitterbuffer latency=100 ! queue max-size-buffers=0 ! rtph264depay ! queue max-size-buffers=0 ! decodebin ! autovideosink sync=false   You can check the results with the 1080p@24fps.