prebuilt image: image_imx-android-13.4.1_6qsabresd u-boot variables: bootcmd=booti mmc2 bootargs=console=ttymxc0,115200 init=/init androidboot.console=ttymxc0 video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24

Sorry I can't find a place to share this input file. It is to reproduce the VPU JPEG decoder issue I reported in Corrupted MJPG decoding result with FSL 3.10.17 BSP on i.MX6Q VPU​

The documentation is about to present a detailed build steps to implement the verification of the integrity of the rootfs for i.MX8ULP.

Question: The following contradicting information regarding the UART clock tree has been seen in the Rev. 1.0  version of the reference manual: Page 813: PLL3_PFD1 -> divide by 6 -> adjustable post divider -> UART Page 839: PLL3 -> divide by 6 -> UART In the old Rev D I found: Page 803: PLL3 -> divide by 6  ... and something about 80MHz The assumption is that correct path would be: PLL3 -> divide by 6 -> post divider -> UART. Answer: The designer said that UART _CLK_ROOT comes from PLL3 (not PLL3:PFD1) and is divided by 6 to produce 80 MHz. I'm waiting for him to confirm that the divider he mentions is CSCDR1[UART_CLK_PODF].

This tutorial describes the complete procedure for calibrating a touchscreen display using Weston, specifically validated with the DY1212W LVDS panel on the following NXP development platforms: i.MX93‑EVK FRDM‑i.MX95 FRDM‑i.MX8MP While the initial calibration performed by Weston works only temporarily, this guide will walk you through configuring the system so that the calibration becomes persistent across reboots. The steps below include performing the initial calibration, editing Weston’s configuration, creating a calibration helper script, and applying udev rules to store the calibration matrix automatically.   Temporary Touchscreen Calibration To begin, run the following command to perform an initial calibration of your touchscreen: weston-touch-calibrator LVDS-1   After running this command, your display should be correctly calibrated. However, this calibration is not persistent, and you will need to recalibrate after every reboot unless you complete the persistence steps below.   Making the Calibration Persistent Follow the steps below to ensure that calibration settings are preserved across system restarts. Step 1: Edit the Weston Configuration File Open the following file: /etc/xdg/weston/weston.ini Under the [libinput] section, add these lines: [libinput] touchscreen_calibrator=true + calibration_helper=/usr/bin/save-calibration.sh This enables the calibration helper script that will automatically save your settings. Step 2: Create the Calibration Helper Script Create a new script at: /usr/bin/save-calibration.sh   Insert the following content: #!/bin/bash # Store the transformation arguments for the resistive touchscreen as udev rule echo 'SUBSYSTEM=="input", KERNEL=="event[0-9]*", ENV{ID_INPUT_TOUCHSCREEN}=="1", ENV{LIBINPUT_CALIBRATION_MATRIX}="'$2' '$3' '$4' '$5' '$6' '$7'"' >> /etc/udev/rules.d/touchscreen.rules   Make the script executable: chmod 755 /usr/bin/save-calibration.sh   Step 3: Restart Weston and Recalibrate Restart the Weston service: systemctl restart weston   Run the calibration tool again to generate the persistent settings: weston-touch-calibrator LVDS-1 reboot   Conclusion After completing all of the steps above, your touchscreen calibration will now persist across reboots, ensuring a consistent user experience even after powering off the board. This configuration allows the system to automatically store and apply calibration data through a udev rule generated by your helper script. If you encounter any issues or require further assistance, feel free to reach out. Best regards, Chavira

GUI Guider version:  1.9.x, 1.10.x LVGL version: v8.x.x , v9.x.x Host software requirements: Ubuntu 20.04, Ubuntu 22.04 or Debian 12 Target  software requirements:  BSP 6.6 or higher  Hardware requirements: FRDM i.MX 93 Development Board i.MX 93 Evaluation Kit FRDM i.MX 91 Development Board i.MX 91 Evaluation Kit i.MX95  Steps: 1. Export your project from the folder GUI-Guider-Projects to your Linux PC. 2. Build an image for iMX9 using The Yocto Project. Based on iMX Yocto Porject Users Guide set directories and download the repo a. Based on iMX Yocto Porject Users Guide set directories and download the repo $ mkdir imx-bsp-6.6 $ cd imx-bsp-6.6 $: repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-scarthgap -m imx-6.6.52-2.2.0.xml $ repo sync Use distro fsl-imx-xwayland and select machine imx93evk and use this commnad with a build folder name: $ MACHINE=imx93evk DISTRO=fsl-imx-xwayland source ./imx-setup-release.sh - b bld-imx93evk b. Use bitbake command to start the build process. Also, add the -c populate_sdk to get the toolchain. $ bitbake imx-image-full -c populate_sdk  c. Install the Yocto toolchain located on <build-folder>/tmp/deploy/sdk/.  $ sudo sh ./fsl-imx-xwayland-glibc-x86_64-imx-image-full-armv8a-imx93evk-toolchain-6.6-scarthgap.sh d. Install ninja utility on the build host $ sudo apt update $ sudo apt upgrade -y $ sudo apt install ninja-build   3. Once your Yocto SDK has been generated and installed, you can build the required binaries using the script attached to this post.      a) Place the script           Copy the script into the same directory where your meta-gui-guider folder is located.      b) Run the script to build the Gui Guider binary           The script includes several options to rebuild, clean, or use a different toolchain in                case you are working with a Yocto SDK version other than the default one (6.6-scarthgap). Build Options Build the Gui Guider binary using the default Yocto SDK ./guider_1.9_project_builder.sh Build the Gui Guider binary using another Yocto SDK version ./guider_1.9_project_builder.sh -t <yocto_sdk_path>/sysroots/x86_64-pokysdk-linux/usr/share/cmake/armv8a-poky-linux-toolchain.cmake Prepare the source code before building ./guider_1.9_project_builder.sh -p Clean the previous build and recompile (Use -t if needed to specify a different toolchain) ./guider_1.9_project_builder.sh -c   4. The generated Gui Guider binary can be found at the following path: /meta-gui-guider/recipes-graphics/gui-guider/gui-guider/build/gui_guider Copy this binary to your board using either USB or SCP, and then execute it directly on the target device.   Using this method provides the flexibility to modify the source code before compilation. This is important because, by default, some configuration options are not available when using Gui Guider directly or when compiling inside Yocto. If you encounter any issues during this process, please open a new thread so we can assist you. Best regards, Chavira

This patch series enables the external 3.3 V and 5 V power rails used by the Raspberry Pi expansion connector on the i.MX93-QSB, i.MX93-FRDM, and i.MX91-FRDM boards. These regulators were already defined in the device tree but left disabled by default. By activating them, the RPI-compatible expansion header can properly power external modules, HATs, and add‑on boards. Changes by board: i.MX93-QSB Enables the 3.3 V and 5 V external supply lines used by the RPI connector.   i.MX93-FRDM Enables the 3.3 V and 5 V external supply lines used by the RPI connector.   i.MX91-FRDM Enables the 3.3 V and 5 V external supply lines used by the RPI connector.   Purpose: Provide proper power to the Raspberry Pi compatible expansion port. Improve hardware compatibility for users attaching external HATs or modules. Align all i.MX9 reference boards to use a consistent power‑tree configuration for the RPI connector.

Assemble wxWidgets version 2.8. TinyX used. Powered by touchscreens 4 "- 8".

Hi team, My customer is facing the issue of unexpected behavior of i.MX6Q SSI. The customer uses SSI as slave/Network mode. And they want to transfer 4 time-slot data. As for the register setting, RFEN0, RFEN1 and RDMAE is set to 1. And only first time slot data is transferred. Do you have any ideas about the cause of this? Thanks, Miyamoto This document was generated from the following discussion: 

It is suggested to create a layer when creating or modifying any metadata file (recipe, configuration file or class). The main reason is simple: modularity. Follow these steps 1. To have access to Yocto scripts, setup the enviroment from the BASE folder fsl-community-bsp $ . setup-environment build 2. Move to the place you want to create your layer and choose a name (e.g. `fsl-custom`) sources $ yocto-layer create fsl-custom # Answer the questions. Make sure the priority is set correctly (higher numbers, # higher priorities). Set the priority equal to the lowest already present, except # when you have introduce a new recipe with the same name as other and want to shadow # the original one. 3. Add any metadata content. Suggestion: Version the layer with Git and upload your local git repo to a server 4. Edit and add the layer to the `build/conf/bblayers.conf` file 5. To verify that your layer is *seen* by BitBake, run the following command under the build folder build $ bitbake-layers show-layers This document was generated from the following discussion: i.MX Yocto Proyect: How can I create a new Layer?

If anyone else has been frustrated by the lack of RT1050 support or is new to NXP products, the MCU On Eclipse blog has been a great help.  For example, see the MCUXpresso IDE V10.1.0 with i.MX RT1052 Crossover Processor article for a very clear overview/quickstart on getting the MIMXRT1050-EVK up and running. This document was generated from the following discussion: RT1050 Developer Resource

hi daiane       find the attached log of gstreamer

ltib 编译的 解码插件包，官网比较难找到的。

Support SSI Master function based on 0001_SSI_ASRC_P2P.patch

Attached is a chunk of the filesystem for the Linux Image https://community.freescale.com/docs/DOC-93887

Question: What does it means by depending on load? Is there a value? This is  related with i.MX6D Answer: The comment about the "load" means the total system load on the 2.5V rail. We understand that people design systems, not just MX6 devices. The documentation confusion stems from the design team changing from allowing customers to use the LDOs to power system devices back to just using the LDOs to power the MX6. Reasons - thermals, and also concern for uncontrolled system noise injection into the MX6 and causing failures.

i.MX6UL OBDS test image

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.  

Attached is a chunk of the Filesystem needed to construct the Linux Image https://community.freescale.com/docs/DOC-93887

this poring is based on the imx415 driver, the capture format is based on raw10, the bsp version is 6.6.52, the patches are attached Disclaimer: − “Any support, information, and technology (“Materials”) provided by NXP are provided AS IS, without any warranty express or implied, and NXP disclaims all direct and indirect liability and damages in connection with the Material to the maximum extent permitted by the applicable law. NXP accepts no liability for any assistance with applications or product design. Materials may only be used in connection with NXP products. Any feedback provided to NXP regarding the Materials may be used by NXP without restriction.”