i.MX Processors Knowledge Base

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX Processors Knowledge Base

Discussions

Sort by:
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  
View full article
  Just sharing some experiences during the development and studying.   Although, it appears some hardwares, it focuses on software to speed up your developing on your  hardware.     杂记共享一下在开发和学习过程中的经验。    虽然涉及一些硬件,但其本身关注软件,希望这些能加速您在自己硬件上的开发。 10/22/2024 iMX93-EVK PWM LED https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/iMX93-EVK-PWM-LED/ta-p/1978047   07/25/2024 iMX secondary boot collection https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/iMX-secondary-boot-collection/ta-p/1916915   07/25/2024 HSM Code-Signing Journey https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/HSM-Code-Signing-Journey/ta-p/1882244 25JUL2024 - add pkcs11 proxy                         HSM Code-Signing Journey_25JUL2024.pdf                          HSM Code-Signing Journey_25JUL2024.txt   06/06/2024 HSM Code-Signing Journey https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/HSM-Code-Signing-Journey/ta-p/1882244     02/07/2024 Device Tree Standalone Compile under Windows https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/Device-Tree-Standalone-Compile-under-Windows/ta-p/1855271   02/07/2024 i.MX8X security overview and AHAB deep dive i.MX8X security overview and AHAB deep dive - NXP Community   11/23/2023 “Standalone” Compile Device Tree https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/Standalone-Compile-Device-Tree/ta-p/1762373     10/26/2023 Linux Dynamic Debug https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/Linux-Dynamic-Debug/ta-p/1746611   08/10/2023 u-boot environment preset for sdcard mirror u-boot environment preset for sdcard mirror - NXP Community   06/06/2023 all(bootloader, device tree, Linux kernel, rootfs) in spi nor demo imx8qxpc0 mek all(bootloader, device tree, Linux kernel, rootfs)... - NXP Community     09/26/2022 parseIVT - a script to help i.MX6 Code Signing parseIVT - a script to help i.MX6 Code Signing - NXP Community   Provide  run under windows   09/16/2022   create sdcard mirror under windows create sdcard mirror under windows - NXP Community     08/03/2022   i.MX8MM SDCARD Secondary Boot Demo https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8MM-SDCARD-Secondary-Boot-Demo/ta-p/1500011     02/16/2022 mx8_ddr_stress_test without UI   https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/mx8-ddr-stress-test-without-UI/ta-p/1414090   12/23/2021 i.MX8 i.MX8X Board Reset https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8-i-MX8X-Board-Reset/ta-p/1391130       12/21/2021 regulator userspace-consumer https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/regulator-userspace-consumer/ta-p/1389948     11/24/2021 crypto af_alg blackkey demo crypto af_alg blackkey demo - NXP Community   09/28/2021 u-boot runtime modify Linux device tree(dtb) u-boot runtime modify Linux device tree(dtb) - NXP Community     08/17/2021 gpio-poweroff demo https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/gpio-poweroff-demo/ta-p/1324306         08/04/2021 How to use gpio-hog demo https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/How-to-use-gpio-hog-demo/ta-p/1317709       07/14/2021 SWUpdate OTA i.MX8MM EVK / i.MX8QXP MEK https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/SWUpdate-OTA-i-MX8MM-EVK-i-MX8QXP-MEK/ta-p/1307416     04/07/2021 i.MX8QXP eMMC Secondary Boot https://community.nxp.com/t5/i-MX-Community-Articles/i-MX8QXP-eMMC-Secondary-Boot/ba-p/1257704#M45       03/25/2021 sc_misc_board_ioctl to access the M4 partition from A core side sc_misc_board_ioctl to access the M4 partition fr... - NXP Community     03/17/2021 How to Changei.MX8X MEK+Base Board  Linux Debug UART https://community.nxp.com/t5/i-MX-Community-Articles/How-to-Change-i-MX8X-MEK-Base-Board-Linux-Debug-UART/ba-p/1246779#M43     03/16/2021 How to Change i.MX8MM evk Linux Debug UART https://community.nxp.com/t5/i-MX-Community-Articles/How-to-Change-i-MX8MM-evk-Linux-Debug-UART/ba-p/1243938#M40       05/06/2020 Linux fw_printenv fw_setenv to access U-Boot's environment variables Linux fw_printenv fw_setenv to access U-Boot's env... - NXP Community     03/30/2020 i.MX6 DDR calibration/stress for Mass Production https://community.nxp.com/docs/DOC-346065     03/25/2020 parseIVT - a script to help i.MX6 Code Signing https://community.nxp.com/docs/DOC-345998     02/17/2020 Start your machine learning journey from tensorflow playground Start your machine learning journey from tensorflow playground      01/15/2020 How to add  iMX8QXP PAD(GPIO) Wakeup How to add iMX8QXP PAD(GPIO) Wakeup    01/09/2020 Understand iMX8QX Hardware Partitioning By Making M4 Hello world Running Correctly https://community.nxp.com/docs/DOC-345359   09/29/2019 Docker On i.MX6UL With Ubuntu16.04 https://community.nxp.com/docs/DOC-344462   09/25/2019 Docker On i.MX8MM With Ubuntu https://community.nxp.com/docs/DOC-344473 Docker On i.MX8QXP With Ubuntu https://community.nxp.com/docs/DOC-344474     08/28/2019 eMMC5.0 vs eMMC5.1 https://community.nxp.com/docs/DOC-344265     05/24/2019 How to upgrade  Linux Kernel and dtb on eMMC without UUU How to upgrade Linux Kernel and dtb on eMMC without UUU     04/12/2019 eMMC RPMB Enhance and GP https://community.nxp.com/docs/DOC-343116   04/04/2019 How to Dump a GPT SDCard Mirror(Android O SDCard Mirror) https://community.nxp.com/docs/DOC-343079   04/04/2019 i.MX Create Android SDCard Mirror https://community.nxp.com/docs/DOC-343078   04/02/2019: i.MX Linux Binary_Demo Files Tips  https://community.nxp.com/docs/DOC-343075   04/02/2019:       Update Set fast boot        eMMC_RPMB_Enhance_and_GP.pdf   02/28/2019: imx_builder --- standalone build without Yocto https://community.nxp.com/docs/DOC-342702   08/10/2018: i.MX6SX M4 MPU Settings For RPMSG update    Update slide CMA Arrangement Consideration i.MX6SX_M4_MPU_Settings_For_RPMSG_08102018.pdf   07/26/2018 Understand ML With Simplest Code https://community.nxp.com/docs/DOC-341099     04/23/2018:     i.MX8M Standalone Build     i.MX8M Standalone Build.pdf     04/13/2018:      i.MX6SX M4 MPU Settings For RPMSG  update            Add slide CMA Arrangement  Consideration     i.MX6SX_M4_MPU_Settings_For_RPMSG_04132018.pdf   09/05/2017:       Update eMMC RPMB, Enhance  and GP       eMMC_RPMB_Enhance_and_GP.pdf 09/01/2017:       eMMC RPMB, Enhance  and GP       eMMC_RPMB_Enhance_and_GP.pdf 08/30/2017:     Dual LVDS for High Resolution Display(For i.MX6DQ/DLS)     Dual LVDS for High Resolution Display.pdf 08/27/2017:  L3.14.28 Ottbox Porting Notes:         L3.14.28_Ottbox_Porting_Notes-20150805-2.pdf MFGTool Uboot Share With the Normal Run One:        MFGTool_Uboot_share_with_NormalRun_sourceCode.pdf Mass Production with programmer        Mass_Production_with_NAND_programmer.pdf        Mass_Production_with_emmc_programmer.pdf AndroidSDCARDMirrorCreator https://community.nxp.com/docs/DOC-329596 L3.10.53 PianoPI Porting Note        L3.10.53_PianoPI_PortingNote_151102.pdf Audio Codec WM8960 Porting L3.10.53 PianoPI        AudioCodec_WM8960_Porting_L3.10.53_PianoPI_151012.pdf TouchScreen PianoPI Porting Note         TouchScreen_PianoPI_PortingNote_151103.pdf Accessing GPIO From UserSpace        Accessing_GPIO_From_UserSpace.pdf        https://community.nxp.com/docs/DOC-343344 FreeRTOS for i.MX6SX        FreeRTOS for i.MX6SX.pdf i.MX6SX M4 fastup        i.MX6SX M4 fastup.pdf i.MX6 SDCARD Secondary Boot Demo        i.MX6_SDCARD_Secondary_Boot_Demo.pdf i.MX6SX M4 MPU Settings For RPMSG        i.MX6SX_M4_MPU_Settings_For_RPMSG_10082016.pdf Security        Security03172017.pdf    NOT related to i.MX, only a short memo
View full article
Information about the transition from the NXP Demo Experience to GoPoint for i.MX Application Processors.
View full article
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
View full article
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).    
View full article
This is an example for user to transfer files between i.MX8MP Linux platform and other devices via Bluetooth. Environment : Hardware : i.MX8MP LPDDR4 EVK Board, Android Phone Software : L6.6.23-2.0.0   Step1 : Build Yocto image and burnt to the SD card or EMMC repo init -u https://github.com/nxp-imx/imx-manifest.git -b imx-linux-scarthgap -m imx-6.6.23-2.0.0.xml repo sync DISTRO=fsl-imx-xwayland MACHINE=imx8mp-lpddr4-evk source imx-setup-release.sh -b build-xwayland Add the following code to "conf/local.conf"          IMAGE_INSTALL:append = " glibc-gconv-utf-16" bitbake imx-image-full uuu -b emmc_all imx-image-full-imx8mp-lpddr4-evk.rootfs-20240919015845.wic Step2 : Test steps Boot board with "imx8mp-evk-usdhc1-m2.dtb" file. load Wi-Fi Firmware           root@imx8mp-lpddr4-evk:~# modprobe moal mod_para=nxp/wifi_mod_para.conf Load BT firmware and enable BT          root@imx8mp-lpddr4-evk:~# modprobe btnxpuart          root@imx8mp-lpddr4-evk:~# hciconfig                    root@imx8mp-lpddr4-evk:~# hciconfig hci0 up connect  the BT of Android Phone          root@imx8mp-lpddr4-evk:~# bluetoothctl          [bluetooth]# default-agent          [bluetooth]# agent on          [bluetooth]# discoverable on          [bluetooth]# scan on          [bluetooth]# scan off                    [bluetooth]# pair 90:F0:52:92:A6:6C          we need to type Yes on board and click 配对 on phone.                           [bluetooth]# connect 90:F0:52:92:A6:6C                 [Meizu16m]# quit          Transfer file          1). Android Phone-> i.MX8MP EVK Board          root@imx8mp-lpddr4-evk:~# /usr/libexec/bluetooth/obexd -a -n -r /root/ & obexctl                   Then select a file on your phone ad choose transfer by Bluetooth.                   2).i.MX8MP EVK Board -> Android Phone          [obex]# connect 90:F0:52:92:A6:6C                   [90:F0:52:92:A6:6C]# send /home/root/test.txt          Note :  1. Do not suggestion use IOS phone. 2. If your i.MX8MP board can not scan your BT device, Suggest change the device BT name and run on "scan on" command again.  
View full article
The purpose of this article is to show how to reduce the boot time on i.MX 8QXP using U-Boot Falcon Mode. The general technique is presented in the AN14093. This article was tested on LF-6.6.23-2.0.0 BSP. How to do it 1. Follow the steps in the i.MX Yocto Project User's Guide and prepare your Yocto building environment. We will further assume that the BSP is in the ~/imx-yocto-bsp directory and the build directory is ~/imx-yocto-bsp/build. 2. Unpack the attached archive in ~/imx-yocto-bsp/sources. This should create the ~/imx-yocto-bsp/sources/meta-imx-fastboot directory.  3. Add the meta-imx-fastboot layer to your build using the following command: bitbake-layers add-layer ~/imx-yocto-bsp/sources/meta-imx-fastboot 4. If you've previously built an image in the same tree, clean the u-boot-imx and imx-boot packages using the following command: bitbake -c clean u-boot-imx imx-boot 5. Build the new image. Out of the box, this package is configured for core-image-minimal. We will show you below how to adapt it for other images: bitbake core-image-minimal 6. Write the resulted image on eMMC/SD using your preferred method and boot the board. 7. By default, the board will boot normally. To enable fast boot, stop the board in U-Boot, and run the following command: u-boot => run prepare_fdt 8. Reboot the board. From this point on, the board should boot in fast mode. Far less messages will be printed by the kernel or systemd during boot. You may further optimize the boot time by removing unnecessary features from the kernel and/or removing unnecessary services started by systemd. Please refer to AN14093. 9. If you ever want to re-enter U-Boot, please keep the 'c' key pressed in the serial console during board power-on. It's easiest if you press and keep the 'c' key pressed before powering on/pressing the reset button. How it works The layer we've added contains patches for U-Boot, ATF and imx-mkimage. In addition, it modifies the core-image-minimal recipe. In U-Boot, the necessary options for Falcon Mode are added in a new configuration file, named imx8qxp_mek_falcon_defconfig, as well as an implementation of the spl_start_uboot() function. In ATF, the device tree load address is added in the correct parameter. In mkimage, two new targets are created: kernel-atf-container.img (to be deployed in the boot partition) and uImage (to be deployed in the rootfs). The change in the core-image-minimal recipe ensures that the new files are copied in the resulting image. If you want to build a different image, you need to copy the content of core-image-minimal.bbappend in a new file, named according to the image you want to build. For example, if you want to build imx-image-full, you could use the following command: cp ~/imx-yocto-bsp/sources/meta-imx-fastboot/recipes-fsl/images/core-image-minimal.bbappend ~/imx-yocto-bsp/sources/meta-imx-fastboot/recipes-fsl/images/imx-image-full.bbappend       *** 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.
View full article
This knowledge base add imx8ulp swupdate support based on AN13872. Uboot patch: add_swupdate_support_for_imx8ulp_in_uboot.patch swupdate-scripts patch: 0001-add-imx8ulp-support-in-swupdate-scripts.patch Note You must generate new key referring  5.4.3.3 Generating a key before build. Commands 1. base image build command   ./assemble_base_image.sh -b imx8ulp -e emmc -d doublecopy -m   2. update image build command   ./swu_update_image_build.sh -e -s ./priv.pem -b imx8ulp -g   3. flash command:   uuu -b emmc_all .\imx-boot-imx8ulp-lpddr4-evk-sd.bin-flash_singleboot_m33 .\swu_doublecopy_rescue_imx8ulp_emmc_20240914.sdcard       Useful links: https://sbabic.github.io/swupdate/building-with-yocto.html#automatic-sha256-in-sw-description https://sbabic.github.io/swupdate/sw-description.html?highlight=hwrevision   
View full article
This article describes how to use the Preempt-RT Linux kernel in the i.MX Linux BSP 6.6.23_2.0.0. This is particularly useful for platforms such as i.MX 95, for which there is not yet a Real-Time Edge Software release.    How to do it    1. Follow the steps in the i.MX Yocto Project User's Guide and build your preferred image, for example core-image-minimal. Will further assume that the BSP is in the ~/imx-yocto-bsp directory and the build directory is ~/imx-yocto-bsp/build. 2. Unpack the attached archive in ~/imx-yocto-bsp/sources. This should create the ~/imx-yocto-bsp/sources/meta-otherkernels directory. This archive will work out of the box for i.MX 95 and i.MX 93, and may require some modifications for other platforms, as described below. 3. Add the meta-otherkernels to your build using the following command: bitbake-layers add-layer ~/imx-yocto-bsp/sources/meta-otherkernels 4. Add the OVERRIDES .= ":preempt-rt" to ~/imx-yocto-bsp/build/conf/local.conf file using the following command: echo 'OVERRIDES .= ":preempt-rt"' >> ~/imx-yocto-bsp/build/conf/local.conf This enables the Preempt-RT kernel for your build. You can always go back to your regular kernel by removing this line from ~/imx-yocto-bsp/build/conf/local.conf. 5. Build again your image. After booting this image, you can check the kernel version using: uname -a      How it works    The meta-otherkernels layer contains a .bbappend  for the linux-imx kernel recipe which replaces the sources URL with the Real-Time Edge kernel when the "preempt-rt" override is active. In addition, due to the fact that the current real-time kernel does not support all the board configurations, the layer config file (meta-otherkernels/conf/layer.conf) removes from the build the device tree files that are not supported (when "preempt-rt" override is active).   If you use this layer for other SoCs (other than i.MX 93/i.MX 95), you may need to edit the meta-otherkernels/conf/layer.conf and add the unsupported device trees. If an  unsupported device tree is left, Yocto will give an error during build.        *** 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.
View full article
  This guide assumes that the developer has knowledge of the V4L2 API and has worked or is familiar with sensor drivers and their operation within the Linux kernel. This guide does not focus on the details of the sensor driver development that you want to port. It is assumed that you already have an existing driver for your sensor, before making the port. The version of the ISP's was 6.6.36 Linux BSP. If a different version is used, it is the developer's responsibility to review the API documentation for the corresponding version, since there may be changes that affect what is indicated in this guide. To port the camera sensor, the following steps must be taken as described in the following sections: Define sensor attributes and create instances. ISS Driver and ISP Media Server. Sensor Calibration Files. VVCAM Driver Creation. Device Tree Modifications. Define Sensor Attributes and Create Instances The following three steps are already implemented in CamDevice and are included for reference only. Step 1: Define the sensor attributes in the IsiSensor_s data structure. Step 2: Define the IsiSensorInstanceConfig_t configuration structure that will be used to create a new sensor instance. Step 3: Call the IsiCreateSensorIss() function to create a new sensor instance. ISS Driver and ISP Media Server Step 0 - Use a driver template as base code: Drivers can be found in $ISP_SOURCES_TOP/units/isi/drv/. For example, the ISP sources, come with the OV4656 and OS08a20 drivers. $ISP_SOURCES_TOP indicates the path of your working directory, where the respective sources are located. Step 1 - Add your <SENSOR> ISS Driver: Create the driver entry for your sensor in the path $ISP_SOURCES_TOP/units/isi/drv/<SENSOR>/source/<SENSOR>.c. Change all occurrences of the respective sensor name within the code, for instance, OV4656 -> <SENSOR>, respecting capital letters where applicable. Step 2 - Check the information on the IsiCamDrvConfig_s data structure: Data members defined in this data structure include the sensor ID (CameraDriverID) and the function pointer to the IsiSensor data structure. By using the address of the IsiCamDrvConfig_s structure, the driver can then access the sensor API attached to the function pointer. The following is an example of the structure: /***************************************************************************** * Each sensor driver needs to declare this struct for ISI load *****************************************************************************/ IsiCamDrvConfig_t IsiCamDrvConfig = {     .CameraDriverID = 0x0000,     .pIsiHalQuerySensor = <SENSOR>_IsiHalQuerySensorIss,     .pfIsiGetSensorIss = <SENSOR>_IsiGetSensorIss, };   Important Note: Modify the CameraDriverID according to the chip ID of your sensor. Apply this change to any Chip ID occurrence within the code. Step 3 - Check sensor macro definitions: In case there is any macro definition in the ISS Driver code, which involves specific properties of the sensor, you should modify it according to your requirements. For example: #define <SENSOR>_MIN_GAIN_STEP         (1.0f/16.0f)   Step 4 - Modify ISP Media Server build tools: Changes required in this step include: Add a CMakeLists.txt file in $ISP_SOURCES_TOP/units/isi/drv/<SENSOR>/ that builds your sensor module. Modify the CMakeLists.txt located at $ISP_SOURCES_TOP/units/isi/drv/CMakeLists.txt to include and reference your sensor directory. Modify the $ISP_SOURCES_TOP/appshell/ and $ISP_SOURCES_TOP/mediacontrol/ build tools, since by default they refer to the construction of a particular sensor, for example, the OV4656, so it is necessary to change the name of the corresponding sensor. Modify the $ISP_SOURCES_TOP/build-all-isp.sh script to reference the sensor modules and generate the corresponding binaries when building the ISP media server instance.   Step 5 - ISP Media Server run script: You need to add the operation modes defined for your sensor in the script. Each operating mode is associated with an order (mode 0, mode 1 ... mode N), a name used to execute the command in the terminal (e.g <sensor>_custom_mode_1), a resolution, and a specific calibration file for the sensor. The script is located at $ISP_SOURCES_TOP/imx/run.sh .   Step 6 - Sensor<X> config: At $ISP_SOURCES_TOP/units/isi/drv/ you can find the files to configure each sensor entry to the ISP, called Sensor0_Entry.cfg and Sensor1_Entry.cfg. There, the associated calibration files are indicated for each sensor operating mode, including the calibration files in XML format and the Dewarp Unit configuration files in JSON format. In addition, the .drv file generated for your sensor is referenced, creating the association between the respective /dev/video<X> node and the sensor driver module outputted from the ISP Media Server. In case you are using only one ISP channel, just modify Sensor0_Entry.cfg. In case you require both instances of the ISP, you will need to modify both files. Sensor Calibration Files It is a requirement for using the ISP, to have a calibration file in XML format, specific to the sensor you are using and according to the resolution and working mode. To obtain the calibration files in XML format, there are 3 options: Use the NXP ISP tuning tool for this you will need to ask for access or sign a NDA document. Pay NXP professional services to do the tune. Pay a third-party vendor to do the tune   VVCAM Driver Creation The changes indicated below are based on the assumption that there is a functional sensor driver in its base form, and that it is compatible with the V4L2 API. From now on we focus on applying the changes suggested in the NXP documentation, specifically to establish the communication of the VVCAM Driver (kernel side) and the ISI Layer. Step 0 - Create the sensor driver entry: Developers must add the driver code to the file located at $ISP_SOURCES_TOP/vvcam/v4l2/sensor/<sensor>/<sensor>_xxxx.c, along with a Makefile for the sensor driver module. In the same way, as indicated in the ISS Driver section, you can refer to one of the sample drivers that are included as part of the ISP sources, to review details about the implementation of the driver and the structure of the required Makefile.   Step 1 - Add the VVCAM mode info data structure array: This array stores all the supported modes information for your sensor. The ISI layer can get all the modes with the VVSENSORIOC_QUERY command. The following is an example of the structure, please fill in the information using the attributes of your sensor and the modes it supports. #include "vvsensor.h" . . .   static struct vvcam_mode_info_s <sensor>_mode_info[] = {         {         .index = 0,         .width = ... ,         .height = ... ,         .hdr_mode = ... ,         .bit_width = ... ,         .data_compress.enable = ... ,         .bayer_pattern = ... ,         .ae_info = {                        .                        .                        .                        },         .mipi_info = {                        .mipi_lane = ... ,                        },         },         {         .index = 1,         .         .         .         }, }; Step 2 - Define sensor client to i2c : Define the client_to_sensor macro (in case you don't have any already) and check the segments of the driver code that require this macro. #define client_to_<sensor>(client)\         container_of(i2c_get_clientdata(client), struct <sensor>, subdev)   Step 3 - Define the V4L2-subdev IOCTL function: Define and implement the <sensor>_priv_ioctl, which is used to receive the commands and parameters passed down by the user space through ioctl() and control the sensor. long <sensor>_priv_ioctl(struct v4l2_subdev *subdev, unsigned int cmd, void *arg) {         struct i2c_client *client = v4l2_get_subdevdata(subdev);         struct <sensor> *sensor = client_to_<sensor>(client);         struct vvcam_sccb_data_s reg;         uint32_t value = 0;         long ret = 0;           if(!sensor){                return -EINVAL;         }           switch (cmd) {         case VVSENSORIOC_G_CLK: {                ret = custom_implementation();                break;         }         case VIDIOC_QUERYCAP: {                ret = custom_implementation();                break;         }         case VVSENSORIOC_QUERY: {                ret = custom_implementation();                break;         }         case VVSENSORIOC_G_CHIP_ID: {                ret = custom_implementation();                break;         }         case VVSENSORIOC_G_RESERVE_ID: {                ret = custom_implementation();                break;         }         case VVSENSORIOC_G_SENSOR_MODE:{                ret = custom_implementation();                break;         }         case VVSENSORIOC_S_SENSOR_MODE: {                ret = custom_implementation();                break;         }         case VVSENSORIOC_S_STREAM: {                ret = custom_implementation();                break;         }         case VVSENSORIOC_WRITE_REG: {                ret = custom_implementation();                break;         }         case VVSENSORIOC_READ_REG: {                ret = custom_implementation();                break;         }         case VVSENSORIOC_S_EXP: {                ret = custom_implementation();                break;         }         case VVSENSORIOC_S_POWER:         case VVSENSORIOC_S_CLK:         case VVSENSORIOC_RESET:         case VVSENSORIOC_S_FPS:         case VVSENSORIOC_G_FPS:         case VVSENSORIOC_S_LONG_GAIN:         case VVSENSORIOC_S_GAIN:         case VVSENSORIOC_S_VSGAIN:         case VVSENSORIOC_S_LONG_EXP:         case VVSENSORIOC_S_VSEXP:          case VVSENSORIOC_S_WB:         case VVSENSORIOC_S_BLC:         case VVSENSORIOC_G_EXPAND_CURVE:                break;         default:                break;         }           return ret; }   As you can see in the example, some cases are implemented but others are not. Developers are free to implement the features they consider necessary, as long as a minimum base of operation of the driver is guaranteed (query commands, read and write registers, among others). It is the developer's responsibility to implement each custom function, for each case or scenario that may arise when interacting with the sensor. In addition to what was shown previously, a link must be created to make the ioctl connection with the driver in question. Link your priv_ioctl function on the v4l2_subdev_core_ops struct, as in the example below: static const struct v4l2_subdev_core_ops <sensor>_core_ops = {         .s_power       = v4l2_s_power,         .subscribe_event = v4l2_ctrl_subdev_subscribe_event,         .unsubscribe_event = v4l2_event_subdev_unsubscribe,      // IOCTL link         .ioctl = <sensor>_priv_ioctl, };   Step 4 - Verify your sensor's private data structure: After performing the modifications suggested, it would be a good practice to double-check your sensor's private data structure properties, in case there is one missing, and also check that the properties are initialized correctly on the driver's probe.   Step 5 - Modify VVCAM V4L2 sensor Makefile : At $ISP_SOURCES_TOP/vvcam/v4l2/sensor/Makefile, include your sensor object as follows: ... obj-m += <sensor>/ ... Important Note: There is a very common issue that appears when working with camera sensor drivers in i.MX8MP platforms. The kernel log message shows something similar to the following: mxc-mipi-csi2.<X>: is_entity_link_setup, No remote pad found! The link setup callback is required by the Media Controller when performing the linking process of the media entities involved in the capture process of the camera. Normally, this callback is triggered by the imx8-media-dev driver included as part of the Kernel sources. To make sure that the problem is not related to your sensor driver, verify the link setup callback is already created in the code, and if is not, you can add the following template: /* Function needed by i.MX8MP */ static int <sensor>_camera_link_setup(struct media_entity *entity,                                    const struct media_pad *local,                                    const struct media_pad *remote, u32 flags) {     /* Return always zero */         return 0; }   /* Add the link setup callback to the media entity operations struct */ static const struct media_entity_operations <sensor>_camera_subdev_media_ops = {         .link_setup = <sensor>_camera_link_setup, };     /* Verify the initialization process of the media entity ops in the sensor driver's probe function*/ static int <sensor>_probe(struct i2c_client *client, ...) {         /* Initialize subdev */         sd = &<sensor>->subdev;         sd->dev = &client->dev;         <sensor>->subdev.internal_ops = ...         <sensor>->subdev.flags |= ...         <sensor->subdev.entity.function = ...     /* Entity ops initialization */         <sensor->subdev.entity.ops = &<sensor>_camera_subdev_media_ops; } In most cases, adding the link setup function will solve the media controller issue, or at least it discards problems on the driver side. Device Tree Modifications On the Device Tree side, it is necessary to enable the ISP channels that will be used. Likewise, it is necessary to disable the ISI channels, which are normally the ones that connect to the MIPI_CSI2 ports to extract raw data from the sensor (in case the ISP is not used). A MIPI_CSI2 port can be mapped to either an ISI channel or an ISP channel, but not both simultaneously. In this guide, we focus on using the ISP, so any other custom configuration that you want to implement may vary from what is shown. In the code below, ISP channel 0 is enabled, and the connection is made to the port where the sensor is connected (mipi_csi_0). &mipi_csi_0 {         status = "okay";         port@0 {         // Example endpoint to <sensor>_ep                mipi0_sensor_ep: endpoint@1 {                        remote-endpoint = <&<sensor>_ep>;                };         }; };   &cameradev {         status = "okay"; };   &isi_0 {         status = "disabled"; };   &isi_1 {         status = "disabled"; };   &isp_0 {         status = "okay"; };   &isp_1 {         status = "disabled"; };   &dewarp {         status = "okay"; }; What is shown above does not represent a complete device tree file, is only a general skeleton of the points you should pay attention to when working with ISP channels. For simplicity, we omitted all the attributes that are normally defined when working with camera sensor drivers and their respective configurations in the i2c port of the hardware.   Note: Due to hardware restrictions when using ISP channels, it is recommended to use the isp_0 channel, when working with only one sensor. In case you need to use two sensors, you can enable both channels, taking into account the limitations regarding the output resolutions and the clock frequency when both channels are working simultaneously. What is not recommended is to use the isp_1 channel when working with a single sensor.   References ISP Independent Sensor Interface (ISI) API reference, I.MX8M Plus Camera Sensor Porting User guide: https://www.nxp.com/webapp/Download?colCode=IMX8MPCSPUG Sensor Calibration tool: https://www.nxp.com/webapp/Download?colCode=AN13565 i.MX8M Plus reference manual: https://www.nxp.com/webapp/Download?colCode=IMX8MPRM  
View full article
The Gui-guilder doesn't provide remote debug function in IDE and we still need use Yocto to build project or copy binary to board rootfs. This knowledge base will provide a solution about how to use VSCode to remote debug LVGL project on i.MX93 EVK board.    Yocto toolchain: L6.6.x GUI GUILDER: v1.8.0   Need to open GUI GUILDER project in VSCode.   1.Scripts in VScode   1.1 build.sh Modify build.sh in <LVGL project>/ports/linux     #!/bin/sh toolchain=$1 if [ -z "$toolchain" ];then toolchain=/opt/fsl-imx-xwayland/6.1-mickledore/sysroots/x86_64-pokysdk-linux/usr/share/cmake/armv8a-poky-linux-toolchain.cmake if [ ! -r $toolchain ];then toolchain=/opt/fsl-imx-xwayland/6.1-langdale/sysroots/x86_64-pokysdk-linux/usr/share/cmake/armv8a-poky-linux-toolchain.cmake fi fi toolchain_path=$(echo $toolchain |sed -E 's,^(.*)/sysroots/.*,\1,') toolchain_arch=armv8a-poky-linux if [ ! -r $toolchain -o ! -r "$toolchain_path/environment-setup-$toolchain_arch" ];then echo "ERROR: Yocto Toolchain not installed?" exit 1 fi if [ -n "$BASH_SOURCE" ]; then ROOTDIR="`readlink -f $BASH_SOURCE | xargs dirname`" elif [ -n "$ZSH_NAME" ]; then ROOTDIR="`readlink -f $0 | xargs dirname`" else ROOTDIR="`readlink -f $PWD | xargs dirname`" fi BUILDDIR=$ROOTDIR/../build rm -fr $BUILDDIR mkdir $BUILDDIR . "$toolchain_path/environment-setup-$toolchain_arch" echo "start build..." cd $ROOTDIR/linux/lv_drivers/wayland/ cmake . make cd $BUILDDIR toolchain_path=/opt/fsl-imx-wayland/6.6-scarthgap/sysroots/x86_64-pokysdk-linux/usr/share/cmake/armv8a-poky-linux-toolchain.cmake cmake -G 'Ninja' .. -DCMAKE_TOOLCHAIN_FILE=$toolchain_path -Wno-dev -DLV_CONF_BUILD_DISABLE_EXAMPLES=1 -DLV_CONF_BUILD_DISABLE_DEMOS=1 -DCMAKE_CXX_FLAGS="-ggd3 -O0" -DCMAKE_BUILD_TYPE=Debug ninja if [ -e gui_guider ];then echo "Binary locates at $(readlink -f gui_guider)" ls -lh gui_guider fi # Copy binary to board scp $BUILDDIR/gui_guider root@192.168.31.243:/opt     1.2 tasks.json     { "version": "2.0.0", "tasks": [ { "label": "Build", "type": "shell", "command": "./build.sh /opt/fsl-imx-wayland/6.6-scarthgap", "options": { "cwd": "${workspaceFolder}/ports/linux" }, "problemMatcher": [ "$gcc" ], } ] }       1.3 launch.json   miDebuggerServerAddress is board ip address.     { "version": "0.2.0", "configurations": [ { "name": "(gdb) Launch", "preLaunchTask": "Build", "type": "cppdbg", "request": "launch", "program": "${workspaceFolder}/build/gui_guider", "args": [], "stopAtEntry": false, "cwd": "${workspaceFolder}/", "environment": [], "externalConsole": false, "MIMode": "gdb", "logging": { "engineLogging": true, "trace": true, "traceResponse": true }, "debugStdLib":true, "miDebuggerPath":"/usr/bin/gdb-multiarch", //DO NOT USE GDB IN SDK!!!! "miDebuggerServerAddress": "192.168.31.243:12345", "setupCommands": [ { "description": "Enable pretty-printing for gdb", "text": "-enable-pretty-printing", "ignoreFailures": true, "text": "set remotetimeout 100", } ] }] }       2. Launch gdbserver on board     export SHELL=/opt/gui_guider gdbserver 192.168.31.243:12345 /opt/gui_guider       3. Debug in VSCode   Click (gdb)launch, the source code will be compiled. Then you will see the breakpoint in program. Enjoy your debug~    
View full article
Introduction Time Synchronization stands for the alignment of time within distributed nodes, pretty critical for real-time applications, control and measurement systems as voice and video networks; all of them being embedded applications. It needs the synchronization of frequency, phase and time between all the nodes and offers action coordination, high precision triggers and event reference or timestamping. [1] A Time Synchronization resource it's the ethernet standard for time PTP or IEEE 1588 standard, its study begin with the physical representation of time information: PPS; Pulse Per Second. An squared wave timed by the capable MACs, in i.MX families we have two MACs of which. Background Customers are interested in this signal, we have an i.MX 8M Plus kernel 5 resource but there is a new processor family using the next major kernel version; 6. [2] We will go through demonstrating PPS on i.MX 93 EVK in both MACs; FEC and EQOS. HW setup i.MX 93 EVK boot over eMMC. Connect power and debug receptacles. Hands-on for FEC or eth0 MAC uSDHC2 pin group conflicts with the pps output pin and you are ought to remove the uSDHC2 nodes and assign the event0 out pin to the FEC pin group as shown below. --- imx93-11x11-evk.dts 2024-08-23 18:19:56.344798901 +0200 +++ imx93-11x11-evk-pps.dts 2024-09-02 21:31:46.569477421 +0200 @@ -100,18 +100,6 @@ regulator-max-microvolt = <1800000>; }; - reg_usdhc2_vmmc: regulator-usdhc2 { - compatible = "regulator-fixed"; - pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_reg_usdhc2_vmmc>; - regulator-name = "VSD_3V3"; - regulator-min-microvolt = <3300000>; - regulator-max-microvolt = <3300000>; - gpio = <&gpio3 7 GPIO_ACTIVE_HIGH>; - off-on-delay-us = <12000>; - enable-active-high; - }; - reg_vdd_12v: regulator-vdd-12v { compatible = "regulator-fixed"; regulator-name = "reg_vdd_12v"; @@ -770,21 +766,6 @@ status = "okay"; }; -&usdhc2 { - pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep"; - pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>; - pinctrl-1 = <&pinctrl_usdhc2_100mhz>, <&pinctrl_usdhc2_gpio>; - pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_gpio>; - pinctrl-3 = <&pinctrl_usdhc2_sleep>, <&pinctrl_usdhc2_gpio_sleep>; - cd-gpios = <&gpio3 00 GPIO_ACTIVE_LOW>; - fsl,cd-gpio-wakeup-disable; - vmmc-supply = <&reg_usdhc2_vmmc>; - bus-width = <4>; - status = "okay"; - no-sdio; - no-mmc; -}; - &usdhc3 { pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep"; pinctrl-0 = <&pinctrl_usdhc3>, <&pinctrl_usdhc3_wlan>; @@ -860,14 +842,15 @@ MX93_PAD_ENET2_RD1__ENET1_RGMII_RD1 0x57e MX93_PAD_ENET2_RD2__ENET1_RGMII_RD2 0x57e MX93_PAD_ENET2_RD3__ENET1_RGMII_RD3 0x57e MX93_PAD_ENET2_RXC__ENET1_RGMII_RXC 0x58e MX93_PAD_ENET2_RX_CTL__ENET1_RGMII_RX_CTL 0x57e MX93_PAD_ENET2_TD0__ENET1_RGMII_TD0 0x57e MX93_PAD_ENET2_TD1__ENET1_RGMII_TD1 0x57e MX93_PAD_ENET2_TD2__ENET1_RGMII_TD2 0x57e MX93_PAD_ENET2_TD3__ENET1_RGMII_TD3 0x57e MX93_PAD_ENET2_TXC__ENET1_RGMII_TXC 0x58e MX93_PAD_ENET2_TX_CTL__ENET1_RGMII_TX_CTL 0x57e + MX93_PAD_SD2_DATA0__ENET1_1588_EVENT0_OUT 0x31e >; }; @@ -887,6 +870,7 @@ MX93_PAD_ENET2_TD3__GPIO4_IO16 0x51e MX93_PAD_ENET2_TXC__GPIO4_IO21 0x51e MX93_PAD_ENET2_TX_CTL__GPIO4_IO20 0x51e + MX93_PAD_SD2_DATA0__GPIO3_IO03 0x31e >; }; @@ -998,75 +982,6 @@ >; }; - pinctrl_reg_usdhc2_vmmc: regusdhc2vmmcgrp { - fsl,pins = < - MX93_PAD_SD2_RESET_B__GPIO3_IO07 0x31e - >; - }; - - pinctrl_usdhc2_gpio: usdhc2gpiogrp { - fsl,pins = < - MX93_PAD_SD2_CD_B__GPIO3_IO00 0x31e - >; - }; - - pinctrl_usdhc2_gpio_sleep: usdhc2gpiogrpsleep { - fsl,pins = < - MX93_PAD_SD2_CD_B__GPIO3_IO00 0x51e - >; - }; - - /* need to config the SION for data and cmd pad, refer to ERR052021 */ - pinctrl_usdhc2: usdhc2grp { - fsl,pins = < - MX93_PAD_SD2_CLK__USDHC2_CLK 0x1582 - MX93_PAD_SD2_CMD__USDHC2_CMD 0x40001382 - MX93_PAD_SD2_DATA0__USDHC2_DATA0 0x40001382 - MX93_PAD_SD2_DATA1__USDHC2_DATA1 0x40001382 - MX93_PAD_SD2_DATA2__USDHC2_DATA2 0x40001382 - MX93_PAD_SD2_DATA3__USDHC2_DATA3 0x40001382 - MX93_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e - >; - }; - - /* need to config the SION for data and cmd pad, refer to ERR052021 */ - pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp { - fsl,pins = < - MX93_PAD_SD2_CLK__USDHC2_CLK 0x158e - MX93_PAD_SD2_CMD__USDHC2_CMD 0x4000138e - MX93_PAD_SD2_DATA0__USDHC2_DATA0 0x4000138e - MX93_PAD_SD2_DATA1__USDHC2_DATA1 0x4000138e - MX93_PAD_SD2_DATA2__USDHC2_DATA2 0x4000138e - MX93_PAD_SD2_DATA3__USDHC2_DATA3 0x4000138e - MX93_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e - >; - }; - - /* need to config the SION for data and cmd pad, refer to ERR052021 */ - pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp { - fsl,pins = < - MX93_PAD_SD2_CLK__USDHC2_CLK 0x15fe - MX93_PAD_SD2_CMD__USDHC2_CMD 0x400013fe - MX93_PAD_SD2_DATA0__USDHC2_DATA0 0x400013fe - MX93_PAD_SD2_DATA1__USDHC2_DATA1 0x400013fe - MX93_PAD_SD2_DATA2__USDHC2_DATA2 0x400013fe - MX93_PAD_SD2_DATA3__USDHC2_DATA3 0x400013fe - MX93_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e - >; - }; - - pinctrl_usdhc2_sleep: usdhc2grpsleep { - fsl,pins = < - MX93_PAD_SD2_CLK__GPIO3_IO01 0x51e - MX93_PAD_SD2_CMD__GPIO3_IO02 0x51e - MX93_PAD_SD2_DATA0__GPIO3_IO03 0x51e - MX93_PAD_SD2_DATA1__GPIO3_IO04 0x51e - MX93_PAD_SD2_DATA2__GPIO3_IO05 0x51e - MX93_PAD_SD2_DATA3__GPIO3_IO06 0x51e - MX93_PAD_SD2_VSELECT__GPIO3_IO19 0x51e - >; - }; - /* need to config the SION for data and cmd pad, refer to ERR052021 */ pinctrl_usdhc3: usdhc3grp { fsl,pins = < The driver also needs the following rework. --- a/drivers/net/ethernet/freescale/fec_ptp.c +++ b/drivers/net/ethernet/freescale/fec_ptp.c @@ -184,7 +184,8 @@ static int fec_ptp_enable_pps(struct fec_enet_private *fep, uint enable) val |= (1 << FEC_T_TF_OFFSET | 1 << FEC_T_TIE_OFFSET); val &= ~(1 << FEC_T_TDRE_OFFSET); val &= ~(FEC_T_TMODE_MASK); - val |= (FEC_HIGH_PULSE << FEC_T_TMODE_OFFSET); + // val |= (FEC_HIGH_PULSE << FEC_T_TMODE_OFFSET); + val |= (FEC_TMODE_TOGGLE << FEC_T_TMODE_OFFSET); writel(val, fep->hwp + FEC_TCSR(fep->pps_channel)); /* Write the second compare event timestamp and calculate After booting the board, run these commands: $ ptp4l -A -4 -H -m -i eth0 & $ echo 1 > /sys/class/ptp/ptp0/pps_enable These will get the SD2_DATA0 or TP1009 running a square wave at 0.5 Hz through setting the ptp0 port with: -A    Select the delay mechanism automatically. Start with E2E and switch to P2P when a peer delay request is received. -4    Select the UDP IPv4 network transport. This is the default transport. -H    Select the hardware time stamping. -m    Print messages to the standard output. Run the next command to set the pps (1 Hz signal): $ echo "0 $(date +%s) 100000000 1 0" > /sys/class/ptp/ptp0/period The last because the current driver needs the actual date and a future start; in this case the signal will start within 100 ms, in order to work. You can try with different start times until the optimal value is found. [3]   Hands-on for EQOS or eth1 MAC This is reduced to the proper devicetree changes, and it does not have driver rework nor pps_enable control file. It uses SD2_CLK or TP1008, so DTS need this adjustment: --- imx93-11x11-evk.dts 2024-08-23 18:19:56.344798901 +0200 +++ imx93-11x11-evk-pps.dts 2024-09-02 21:31:46.569477421 +0200 @@ -100,18 +100,6 @@ regulator-max-microvolt = <1800000>; }; - reg_usdhc2_vmmc: regulator-usdhc2 { - compatible = "regulator-fixed"; - pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_reg_usdhc2_vmmc>; - regulator-name = "VSD_3V3"; - regulator-min-microvolt = <3300000>; - regulator-max-microvolt = <3300000>; - gpio = <&gpio3 7 GPIO_ACTIVE_HIGH>; - off-on-delay-us = <12000>; - enable-active-high; - }; - reg_vdd_12v: regulator-vdd-12v { compatible = "regulator-fixed"; regulator-name = "reg_vdd_12v"; @@ -770,21 +766,6 @@ status = "okay"; }; -&usdhc2 { - pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep"; - pinctrl-0 = <&pinctrl_usdhc2>, <&pinctrl_usdhc2_gpio>; - pinctrl-1 = <&pinctrl_usdhc2_100mhz>, <&pinctrl_usdhc2_gpio>; - pinctrl-2 = <&pinctrl_usdhc2_200mhz>, <&pinctrl_usdhc2_gpio>; - pinctrl-3 = <&pinctrl_usdhc2_sleep>, <&pinctrl_usdhc2_gpio_sleep>; - cd-gpios = <&gpio3 00 GPIO_ACTIVE_LOW>; - fsl,cd-gpio-wakeup-disable; - vmmc-supply = <&reg_usdhc2_vmmc>; - bus-width = <4>; - status = "okay"; - no-sdio; - no-mmc; -}; - &usdhc3 { pinctrl-names = "default", "state_100mhz", "state_200mhz", "sleep"; pinctrl-0 = <&pinctrl_usdhc3>, <&pinctrl_usdhc3_wlan>; @@ -822,14 +802,15 @@ MX93_PAD_ENET1_RD1__ENET_QOS_RGMII_RD1 0x57e MX93_PAD_ENET1_RD2__ENET_QOS_RGMII_RD2 0x57e MX93_PAD_ENET1_RD3__ENET_QOS_RGMII_RD3 0x57e MX93_PAD_ENET1_RXC__CCM_ENET_QOS_CLOCK_GENERATE_RX_CLK 0x58e MX93_PAD_ENET1_RX_CTL__ENET_QOS_RGMII_RX_CTL 0x57e MX93_PAD_ENET1_TD0__ENET_QOS_RGMII_TD0 0x57e MX93_PAD_ENET1_TD1__ENET_QOS_RGMII_TD1 0x57e MX93_PAD_ENET1_TD2__ENET_QOS_RGMII_TD2 0x57e MX93_PAD_ENET1_TD3__ENET_QOS_RGMII_TD3 0x57e MX93_PAD_ENET1_TXC__CCM_ENET_QOS_CLOCK_GENERATE_TX_CLK 0x58e MX93_PAD_ENET1_TX_CTL__ENET_QOS_RGMII_TX_CTL 0x57e + MX93_PAD_SD2_CLK__ENET_QOS_1588_EVENT0_OUT 0x31e >; }; @@ -849,6 +830,7 @@ MX93_PAD_ENET1_TD3__GPIO4_IO02 0x31e MX93_PAD_ENET1_TXC__GPIO4_IO07 0x31e MX93_PAD_ENET1_TX_CTL__GPIO4_IO06 0x31e + MX93_PAD_SD2_CLK__GPIO3_IO01 0x31e >; }; @@ -998,75 +982,6 @@ >; }; - pinctrl_reg_usdhc2_vmmc: regusdhc2vmmcgrp { - fsl,pins = < - MX93_PAD_SD2_RESET_B__GPIO3_IO07 0x31e - >; - }; - - pinctrl_usdhc2_gpio: usdhc2gpiogrp { - fsl,pins = < - MX93_PAD_SD2_CD_B__GPIO3_IO00 0x31e - >; - }; - - pinctrl_usdhc2_gpio_sleep: usdhc2gpiogrpsleep { - fsl,pins = < - MX93_PAD_SD2_CD_B__GPIO3_IO00 0x51e - >; - }; - - /* need to config the SION for data and cmd pad, refer to ERR052021 */ - pinctrl_usdhc2: usdhc2grp { - fsl,pins = < - MX93_PAD_SD2_CLK__USDHC2_CLK 0x1582 - MX93_PAD_SD2_CMD__USDHC2_CMD 0x40001382 - MX93_PAD_SD2_DATA0__USDHC2_DATA0 0x40001382 - MX93_PAD_SD2_DATA1__USDHC2_DATA1 0x40001382 - MX93_PAD_SD2_DATA2__USDHC2_DATA2 0x40001382 - MX93_PAD_SD2_DATA3__USDHC2_DATA3 0x40001382 - MX93_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e - >; - }; - - /* need to config the SION for data and cmd pad, refer to ERR052021 */ - pinctrl_usdhc2_100mhz: usdhc2-100mhzgrp { - fsl,pins = < - MX93_PAD_SD2_CLK__USDHC2_CLK 0x158e - MX93_PAD_SD2_CMD__USDHC2_CMD 0x4000138e - MX93_PAD_SD2_DATA0__USDHC2_DATA0 0x4000138e - MX93_PAD_SD2_DATA1__USDHC2_DATA1 0x4000138e - MX93_PAD_SD2_DATA2__USDHC2_DATA2 0x4000138e - MX93_PAD_SD2_DATA3__USDHC2_DATA3 0x4000138e - MX93_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e - >; - }; - - /* need to config the SION for data and cmd pad, refer to ERR052021 */ - pinctrl_usdhc2_200mhz: usdhc2-200mhzgrp { - fsl,pins = < - MX93_PAD_SD2_CLK__USDHC2_CLK 0x15fe - MX93_PAD_SD2_CMD__USDHC2_CMD 0x400013fe - MX93_PAD_SD2_DATA0__USDHC2_DATA0 0x400013fe - MX93_PAD_SD2_DATA1__USDHC2_DATA1 0x400013fe - MX93_PAD_SD2_DATA2__USDHC2_DATA2 0x400013fe - MX93_PAD_SD2_DATA3__USDHC2_DATA3 0x400013fe - MX93_PAD_SD2_VSELECT__USDHC2_VSELECT 0x51e - >; - }; - - pinctrl_usdhc2_sleep: usdhc2grpsleep { - fsl,pins = < - MX93_PAD_SD2_CLK__GPIO3_IO01 0x51e - MX93_PAD_SD2_CMD__GPIO3_IO02 0x51e - MX93_PAD_SD2_DATA0__GPIO3_IO03 0x51e - MX93_PAD_SD2_DATA1__GPIO3_IO04 0x51e - MX93_PAD_SD2_DATA2__GPIO3_IO05 0x51e - MX93_PAD_SD2_DATA3__GPIO3_IO06 0x51e - MX93_PAD_SD2_VSELECT__GPIO3_IO19 0x51e - >; - }; - /* need to config the SION for data and cmd pad, refer to ERR052021 */ pinctrl_usdhc3: usdhc3grp { fsl,pins = < After boot, issue these commands: $ ptp4l -A -4 -H -m -i eth1 & $ echo "0 $(date +%s) 1000000000 1 0" > /sys/class/ptp/ptp1/period You will have an squared wave of 1 Hz running within 1 s with the same settings as the FEC setup.   Conclusion Both PPS can run in the same image changes and DTS changes, proven in imx-linux-nanbield branch, with the manifest imx-6.6.3-1.0.0.xml. And it's the start of testing IEEE 1588 and syncing capabilities of this i.MX 9 series processors. Sources [1] http://events17.linuxfoundation.org/sites/events/files/slides/elc_insop_2015.pdf [2] https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8-serials-IEEE1588-1pps-test-procedure/ta-p/1490634 [3] https://github.com/nxp-imx/linux-imx/blob/b586a521770e508d1d440ccb085c7696b9d6d387/Documentation/ABI/testing/sysfs-ptp#L2
View full article
P3T1755 Demo   In this space I want to show you the things that you can create usign our products.   In  this demo I demostrate a use case creating a GUI for a Temperature Sensor.   We can create modern GUIs and more with LVGL combined with our powerful processors.               CPU USAGE As we can see  the CPU usage for this demo is around 2%   Pictures         This demo is based on the previous publused articles.   References: https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/Adding-support-to-P3T1755-on-Linux/ta-p/1855874 https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/How-to-run-LGVL-on-iMX-using-framebuffer/ta-p/1853768  
View full article
  Some customers want to expose their i3c device on the /dev, In order to develop their i3c APP or operation the i3c device like I2C. But in our default BSP code, we do not support this feature for I3C device, This article will introduce how to make the i3c device expose to the user space. Board : i.MX 93 EVK BSP Version : lf-6.1.55-2.2.0 I3C device : LSM6DSOXTR Step 1 : Rework the i.MX93 EVK Board, Install the R1010.      Step 2 : Apply the add_i3c_device_to_dev.patch file to the linux kernel code              Command : git apply add_i3c_device_to_dev.patch Step 3 : Re-compile the kernel Image file.              Command : make imx_v8_defconfig                                  make Step 4 : Boot your board with "imx93-11x11-evk-i3c.dtb" file and see if you can see the I3C device on the /dev directory. Result : We can see the i3c device is appeared in /dev directory, The i2c-8 is an i2c device mounted to the i3c bus. The i3c is backward compatible with i2c device. It will simulate the I2C signal loading i2c device.                 PS : You can also use the i2ctool detect i2c-8 device. As shown in the following picture:   Note : If you need the patch file, Please contact me any time for free.
View full article
Ftrace is powerful tracing utility embedded in Linux kernel. It provides a very good method for kernel developer to get insights of the kernel behavior. While official kernel doc for ftrace is somehow long and complex, this document provides a quicker and simpler way to get start with ftrace.
View full article
This guide is a continuation from our latest Debian 12 Installation Guide for iMX8MM, iMX8MP, iMX8MN and iMX93. Here we will describe the process to install the multimedia and hardware acceleration packages, specifically GPU, VPU and Gstreamer on i.MX8M Mini, i.MX8M Plus and i.MX8M Nano. The guide is based on the one provided by our colleague Build Ubuntu For i.MX8 Series Platform - NXP Community, which requires to previously build an image using Yocto Project with the following distro and image name. Distro name - fsl-imx-wayland Image name – imx-image-multimedia For more information please check our BSP documentation i.MX Yocto Project User’s Guide.   Hardware Requirements Linux Host Computer (Ubuntu 20.04 or later) USB Card reader or Micro SD to SD adapter SD Card Evaluation Kit Board for the i.MX8M Nano, i.MX8M Mini, i.MX8M Plus   Software Requirements Linux Ubuntu (20.04 tested) or Debian for Host Computer BSP version 6.1.55 built with Yocto Project   After built the image we can start the installation by following the steps below:   GPU Installation The GPU Installation consists of copy the files from packages imx-gpu-g2d, imx-gpu-viv, libdrm to the Debian system. As our latest installation guide, we will continue naming “mountpoint” to the directory where Debian system is mounted on our host machine. Regarding the path provided on each step, we put labels <build-path> and <machine> that you will need to change based on your environment. These are the paths that Yocto Project uses to save the packages. However, this could change on your environment and you can find the work directory from each package using the following command: bitbake -e <package-name> | grep ^WORKDIR= This command will show you the absolute path of the package work directory. 1. Install GPU Packages $ sudo cp -Pra <build-path>/tmp/work/armv8a-<machine>-poky-linux/imx-gpu-g2d/6.4.11.p2.2-r0/image/* mountpoint $ sudo cp -Pra <build-path>/tmp/work/armv8a-<machine>-poky-linux/imx-gpu-viv/1_6.4.11.p2.2-aarch64-r0/image/* mountpoint $ sudo cp -Pra <build-path>/tmp/work/armv8a-<machine>-poky-linux/libdrm/2.4.115.imx-r0/image/* mountpoint   2. Install Linux IMX Headers and IMX Parser $ sudo cp -Pra <build-path>/tmp/work/armv8a-<machine>-poky-linux/linux-imx-headers/6.1-r0/image/* mountpoint $ sudo cp -Pra <build-path>/tmp/work/armv8a-poky-linux/imx-parser/4.8.2-r0/image/* mountpoint   3. Use chroot $ sudo LANG=C.UTF-8 chroot mountpoint/ qemu-aarch64-static /bin/bash   4. Install Dependencies $ apt install libudev-dev libinput-dev libxkbcommon-dev libpam0g-dev libx11-xcb-dev libxcb-xfixes0-dev libxcb-composite0-dev libxcursor-dev libxcb-shape0-dev libdbus-1-dev libdbus-glib-1-dev libsystemd-dev libpixman-1-dev libcairo2-dev libffi-dev libxml2-dev kbd libexpat1-dev autoconf automake libtool meson cmake ssh net-tools network-manager iputils-ping rsyslog bash-completion htop resolvconf dialog vim udhcpc udhcpd git v4l-utils alsa-utils git gcc less autoconf autopoint libtool bison flex gtk-doc-tools libglib2.0-dev libpango1.0-dev libatk1.0-dev kmod pciutils libjpeg-dev   5. Create a folder for Multimedia Installation. Here we will clone all the multimedia repositories.  $ mkdir multimedia_packages $ cd multimedia_packages   6. Build Wayland $ git clone https://gitlab.freedesktop.org/wayland/wayland.git $ cd wayland $ git checkout 1.22.0 $ meson setup build --prefix=/usr -Ddocumentation=false -Ddtd_validation=true $ cd build $ ninja install   7. Build Wayland Protocols IMX $ git clone https://github.com/nxp-imx/wayland-protocols-imx.git $ cd wayland-protocols-imx $ git checkout wayland-protocols-imx-1.32 $ meson setup build --prefix=/usr -Dtests=false $ cd build $ ninja install   8. Build Weston $ git clone https://github.com/nxp-imx/weston-imx.git $ cd weston-imx $ git checkout weston-imx-11.0.3 $ meson setup build --prefix=/usr -Dpipewire=false -Dsimple-clients=all -Ddemo-clients=true -Ddeprecated-color-management-colord=false -Drenderer-gl=true -Dbackend-headless=false -Dimage-jpeg=true -Drenderer-g2d=true -Dbackend-drm=true -Dlauncher-libseat=false -Dcolor-management-lcms=false -Dbackend-rdp=false -Dremoting=false -Dscreenshare=true -Dshell-desktop=true -Dshell-fullscreen=true -Dshell-ivi=true -Dshell-kiosk=true -Dsystemd=true -Dlauncher-logind=true -Dbackend-drm-screencast-vaapi=false -Dbackend-wayland=false -Dimage-webp=false -Dbackend-x11=false -Dxwayland=false $ cd build $ ninja install   VPU Installation To install VPU and Gstreamer please follow the steps below: 1. Install firmware-imx $ sudo cp -Pra <build-path>/tmp/work/all-poky-linux/firmware-imx/1_8.22-r0/image/lib/* mountpoint/lib/   2. Install VPU Driver $ sudo cp -Pra <build-path>/tmp/work/armv8a-<machine>-poky-linux/imx-vpu-hantro/1.31.0-r0/image/* mountpoint $ sudo cp -Pra <build-path>/tmp/work/armv8a-<machine>-poky-linux/imx-vpuwrap/git-r0/image/* mountpoint   3. Use chroot $ sudo LANG=C.UTF-8 chroot mountpoint/ qemu-aarch64-static /bin/bash   4. Install dependencies for Gstreamer Plugins $ apt install libgirepository1.0-dev gettext liborc-0.4-dev libasound2-dev libogg-dev libtheora-dev libvorbis-dev libbz2-dev libflac-dev libgdk-pixbuf-2.0-dev libmp3lame-dev libmpg123-dev libpulse-dev libspeex-dev libtag1-dev libbluetooth-dev libusb-1.0-0-dev libcurl4-openssl-dev libssl-dev librsvg2-dev libsbc-dev libsndfile1-dev   5. Change directory to multimedia packages. $ cd multimedia-packages   6. Build gstreamer $ git clone https://github.com/nxp-imx/gstreamer -b lf-6.1.55-2.2.0 $ cd gstreamer $ meson setup build --prefix=/usr -Dintrospection=enabled -Ddoc=disabled -Dexamples=disabled -Ddbghelp=disabled -Dnls=enabled -Dbash-completion=disabled -Dcheck=enabled -Dcoretracers=disabled -Dgst_debug=true -Dlibdw=disabled -Dtests=enabled -Dtools=enabled -Dtracer_hooks=true -Dlibunwind=disabled -Dc_args=-I/usr/include/imx $ cd build $ ninja install   7. Build gst-plugins-base $ git clone https://github.com/nxp-imx/gst-plugins-base -b lf-6.1.55-2.2.0 $ cd gst-plugins-base $ meson setup build --prefix=/usr -Dalsa=enabled -Dcdparanoia=disabled -Dgl-graphene=disabled -Dgl-jpeg=disabled -Dopus=disabled -Dogg=enabled -Dorc=enabled -Dpango=enabled -Dgl-png=enabled -Dqt5=disabled -Dtheora=enabled -Dtremor=disabled -Dvorbis=enabled -Dlibvisual=disabled -Dx11=disabled -Dxvideo=disabled -Dxshm=disabled -Dc_args=-I/usr/include/imx $ cd build $ ninja install   8. Build gst-plugins-good $ git clone https://github.com/nxp-imx/gst-plugins-good -b lf-6.1.55-2.2.0 $ cd gst-plugins-good $ meson setup build --prefix=/usr -Dexamples=disabled -Dnls=enabled -Ddoc=disabled -Daalib=disabled -Ddirectsound=disabled -Ddv=disabled -Dlibcaca=disabled -Doss=enabled -Doss4=disabled -Dosxaudio=disabled -Dosxvideo=disabled -Dshout2=disabled -Dtwolame=disabled -Dwaveform=disabled -Dasm=disabled -Dbz2=enabled -Dcairo=enabled -Ddv1394=disabled -Dflac=enabled -Dgdk-pixbuf=enabled -Dgtk3=disabled -Dv4l2-gudev=enabled -Djack=disabled -Djpeg=enabled -Dlame=enabled -Dpng=enabled -Dv4l2-libv4l2=disabled -Dmpg123=enabled -Dorc=enabled -Dpulse=enabled -Dqt5=disabled -Drpicamsrc=disabled -Dsoup=enabled -Dspeex=enabled -Dtaglib=enabled -Dv4l2=enabled -Dv4l2-probe=true -Dvpx=disabled -Dwavpack=disabled -Dximagesrc=disabled -Dximagesrc-xshm=disabled -Dximagesrc-xfixes=disabled -Dximagesrc-xdamage=disabled -Dc_args=-I/usr/include/imx $ cd build $ ninja install   9. Build gst-plugins-bad $ git clone https://github.com/nxp-imx/gst-plugins-bad -b lf-6.1.55-2.2.0 $ cd gst-plugins-bad $ meson setup build --prefix=/usr -Dintrospection=enabled -Dexamples=disabled -Dnls=enabled -Dgpl=disabled -Ddoc=disabled -Daes=enabled -Dcodecalpha=enabled -Ddecklink=enabled -Ddvb=enabled -Dfbdev=enabled -Dipcpipeline=enabled -Dshm=enabled -Dtranscode=enabled -Dandroidmedia=disabled -Dapplemedia=disabled -Dasio=disabled -Dbs2b=disabled -Dchromaprint=disabled -Dd3dvideosink=disabled -Dd3d11=disabled -Ddirectsound=disabled -Ddts=disabled -Dfdkaac=disabled -Dflite=disabled -Dgme=disabled -Dgs=disabled -Dgsm=disabled -Diqa=disabled -Dkate=disabled -Dladspa=disabled -Dldac=disabled -Dlv2=disabled -Dmagicleap=disabled -Dmediafoundation=disabled -Dmicrodns=disabled -Dmpeg2enc=disabled -Dmplex=disabled -Dmusepack=disabled -Dnvcodec=disabled -Dopenexr=disabled -Dopenni2=disabled -Dopenaptx=disabled -Dopensles=disabled -Donnx=disabled -Dqroverlay=disabled -Dsoundtouch=disabled -Dspandsp=disabled -Dsvthevcenc=disabled -Dteletext=disabled -Dwasapi=disabled -Dwasapi2=disabled -Dwildmidi=disabled -Dwinks=disabled -Dwinscreencap=disabled -Dwpe=disabled -Dzxing=disabled -Daom=disabled -Dassrender=disabled -Davtp=disabled -Dbluez=enabled -Dbz2=enabled -Dclosedcaption=enabled -Dcurl=enabled -Ddash=enabled -Ddc1394=disabled -Ddirectfb=disabled -Ddtls=disabled -Dfaac=disabled -Dfaad=disabled -Dfluidsynth=disabled -Dgl=enabled -Dhls=enabled -Dkms=enabled -Dcolormanagement=disabled -Dlibde265=disabled -Dcurl-ssh2=disabled -Dmodplug=disabled -Dmsdk=disabled -Dneon=disabled -Dopenal=disabled -Dopencv=disabled -Dopenh264=disabled -Dopenjpeg=disabled -Dopenmpt=disabled -Dhls-crypto=openssl -Dopus=disabled -Dorc=enabled -Dresindvd=disabled -Drsvg=enabled -Drtmp=disabled -Dsbc=enabled -Dsctp=disabled -Dsmoothstreaming=enabled -Dsndfile=enabled -Dsrt=disabled -Dsrtp=disabled -Dtinyalsa=disabled -Dtinycompress=enabled -Dttml=enabled -Duvch264=enabled -Dv4l2codecs=disabled -Dva=disabled -Dvoaacenc=disabled -Dvoamrwbenc=disabled -Dvulkan=disabled -Dwayland=enabled -Dwebp=enabled -Dwebrtc=disabled -Dwebrtcdsp=disabled -Dx11=disabled -Dx265=disabled -Dzbar=disabled -Dc_args=-I/usr/include/imx $ cd build $ ninja install   10. Build imx-gst1.0-plugin $ git clone https://github.com/nxp-imx/imx-gst1.0-plugin -b lf-6.1.55-2.2.0 $ cd imx-gst1.0-plugin $ meson setup build --prefix=/usr -Dplatform=MX8 -Dc_args=-I/usr/include/imx $ cd build $ ninja install   11. Exit chroot $ exit   Verify Installation For verification process, boot your target from the SD Card. (Review your specific target documentation) 1. Verify Weston For this verification you will need to be root user. # export XDG_RUNTIME_DIR=/run/user/0 # weston   2. Verify VPU and Gstreamer Use the following Gstreamer pipeline for Hardware Accelerated VPU Encode. # gst-launch-1.0 videotestsrc ! video/x-raw, format=I420, width=640, height=480 ! vpuenc_h264 ! filesink location=test.mp4   Then you can reproduce the file with this command: # gplay-1.0 test.mp4   Finally, you have installed and verified the GPU, VPU and Multimedia packages. Now, you can start testing audio and video applications.
View full article
Hello, here Jorge. On this post I will explain how to enable MQS1 on i.MX8ULP. As background about how to setup the environment to build the image using Yocto, please take a look on our i.MX Yocto Project User's Guide: Requirements: i.MX 8ULP EVK. Serial console emulator (Tera Term, Putty, etc.). USB Type-C cable. Micro USB cable. Headphones/speakers. Linux PC. Build done in Linux 6.6.23_2.0.0. i.MX8ULP audio subsystem. i.MX 8ULP extends audio capabilities on i.MX 7ULP by adding dedicated DSP cores for voice trigger and audio processing, enabling lower latency and power efficiency to support variety of audio applications. Some of hardware blocks implemented on 8ULP to support audio use cases are the next: Cadence Fusion F1 DSP processor. Cadence HiFi4 DSP processor. PowerQuad hardware accelerator with fixed and floating + FFT. Digital Microphone interface with support of up-to 8 PDM channels. Up-to 8 independent SAI instances. Up-to 2 Medium Quality Sound (MQS). Sony/Philips Digital interface (SPDIF). As is described before, MQS0 and MQS1 are part of real time domain and application domain respectively. I’m going to focus this post on how to enable MQS1 on application domain. Medium Quality Sound (MQS)  This module is basically generates a PWM from PCM audio data. For the major part of typical audio applications will require an external CODEC to deliver the audio quality but, sometimes where the application does not demand this quality, MQS can provide a medium quality audio via GPIO pin that can directly drive the audio output to a speaker or headphone via inexpensive external amplifier/buffer instead of CODEC. The design of the MQS can be described as follows: Input the PCM audio data (from SAI) into a 16-bit register. Up-sample data to match PWM switching frequency. Perform a simple 2nd order Sigma-Delta smooth on the current data versus previous data. Convert the PCM register into a 6-bit PWM width register and output through a GPIO pin.   How to enable it? By default, our BSP does not enable clock for MQS1. This clock is controlled on CGC1 (AD), specifically on MQS1CLK (Multiplexer to select the audio clock connected to the MQS clock input). So, it is needed to modify imx8ulp-clock.h and clk-imx8ulp.c. Please take a look on patch attached at the end of this post to see the modification in drivers easily. These drivers have the definition/configuration for MQS1_SEL in CGC1 and needs to be added as follows: MQS1_SEL definition needs to bed added in imx8ulp-clock.h: #define IMX8ULP_CLK_MQS1_SEL 56 #define IMX8ULP_CLK_CGC1_END 57 MQS1_SEL configuration needs to be added in imx8ulp_clk_cgc1_init of clk-imx8ulp.c: clks[IMX8ULP_CLK_MQS1_SEL] = imx_clk_hw_mux2("mqs1_sel", base + 0x90c, 0, 2, sai45_sels, ARRAY_SIZE(sai45_sels)); Also, it is necessary to configure MQS1 on device tree of i.MX8ULP. Add this in soc: soc@0 of imx8ulp.dtsi: mqs1: mqs@0x29290064 { reg = <0x29290064 0x4>; compatible = "fsl,imx8qm-mqs"; assigned-clocks = <&cgc1 IMX8ULP_CLK_MQS1_SEL>; assigned-clock-parents = <&cgc1 IMX8ULP_CLK_SPLL3_PFD1_DIV1>; clocks = <&cgc1 IMX8ULP_CLK_MQS1_SEL>, <&cgc1 IMX8ULP_CLK_MQS1_SEL>; clock-names = "core", "mclk"; status = "disabled"; }; And create a new device tree, in this case is going to be named imx8ulp-evk-mqs.dts and is as follows: #include "imx8ulp-evk.dts" / { sound-simple-mqs { compatible = "simple-audio-card"; simple-audio-card,name = "imx-simple-mqs"; simple-audio-card,frame-master = <&sndcpu>; simple-audio-card,bitclock-master = <&sndcpu>; simple-audio-card,dai-link@0 { format = "left_j"; sndcpu: cpu { sound-dai = <&sai4>; }; codec { sound-dai = <&mqs1>; }; }; }; }; &cgc1 { assigned-clock-rates = <24576000>; }; &iomuxc1 { pinctrl_mqs1: mqs1grp { fsl,pins = < MX8ULP_PAD_PTF7__MQS1_LEFT 0x43 >; }; }; &mqs1 { #sound-dai-cells = <0>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_mqs1>; status = "okay"; }; &sai4 { #sound-dai-cells = <0>; assigned-clocks = <&cgc1 IMX8ULP_CLK_SAI4_SEL>; assigned-clock-parents = <&cgc1 IMX8ULP_CLK_SPLL3_PFD1_DIV1>; status = "okay"; }; Let’s apply these changes on our BSP, in my case I’m going to create a new layer in Yocto to add these modifications with a patch that can be found at the end on this post, here the steps: Install essential Yocto Project host packages: $ sudo apt install gawk wget git diffstat unzip texinfo gcc build-essential chrpath socat cpio python3 python3-pip python3-pexpect xz-utils debianutils iputils-ping python3-git python3-jinja2 python3-subunit zstd liblz4-tool file locales libacl1 Install the “repo” utility: $ mkdir ~/bin $ curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo $ chmod a+x ~/bin/repo $ export PATH=~/bin:$PATH Set up Git: $ git config --global user.name "Your Name" $ git config --global user.email "Your Email" $ git config –list Download the i.MX Yocto Project Community BSP recipe layers and create build folder: $ mkdir imx-yocto-bsp $ cd imx-yocto-bsp $ repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-scarthgap -m imx-6.6.23-2.0.0.xml $ repo sync $ DISTRO=fsl-imx-wayland MACHINE=imx8ulp-lpddr4-evk source imx-setup-release.sh -b 8ulp_build Create the new layer: $ cd ~/imx-yocto-bsp/sources $ bibake-layers create-layer meta-mqs $ cd meta-mqs conf/layer.conf should be as follows: BBPATH .= ":${LAYERDIR}" BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \ ${LAYERDIR}/recipes-*/*/*.bbappend" BBFILE_COLLECTIONS += "meta-mqs" BBFILE_PATTERN_meta-mqs = "^${LAYERDIR}/" BBFILE_PRIORITY_meta-mqs = "6" LAYERSERIES_COMPAT_meta-mqs = "nanbield" Let’s change the recipe: $ sudo rm -r recipes-example $ mkdir -p recipes-kernel/linux/files 0001-8ULP-MQS-Enable.patch should be copied to ~/imx-yocto-bsp/sources/meta-mqs/recipes-kernel/linux/files Add an append (on this case is called “linux-imx_%.bbappend”)to change the recipe with next content: FILESEXTRAPATHS:prepend := "${THISDIR}/files:" SRC_URI += "file:// 0001-8ULP-MQS-Enable.patch " addtask copy_dts after do_unpack before do_prepare_recipe_sysroot do_copy_dts () { if [ -n "${DTS_FILE}" ]; then if [ -f ${DTS_FILE} ]; then echo "do_copy_dts: copying ${DTS_FILE} in ${S}/arch/arm64/boot/dts/freescale" cp ${DTS_FILE} ${S}/arch/arm64/boot/dts/freescale/ fi fi } The next step is add the layer and build the image: $ cd ~/imx-yocto-bsp/8ulp_build $ bitbake-layers add-layer ~/imx-yocto-bsp/sources/meta-mqs Confirm that the layer has been added: $ bitbake-layers show-layers Build the image: $ bitbake imx-image-multimedia i.MX8ULP EVK limitations The i.MX8ULP has the next MQS1 pins available: But, in the EVK board, the mayor part of these pins are used for other functions such as: - Push button: - MIPI DSI:  - Etc… So, take the output signal of MQS1 pins of EVK board is difficult, in this article, I’m going to configure PTF7 only (MQS1_left) for practicality. If you are working with this board and you need to use these pins for MQS function you will need to manipulate the traces and take the required signals. If you are designing a custom board, planning is essential to avoid this issue. Flash the board. One the build has been finished, we will have the necessary files to flash the board and test it. If you are not too familiarized with this process I suggest you take a look on this post. First, put the board in serial download mode changing the boot configuration switches on the board:   The next step is connecting the power cable, micro-USB cable on the debug port and USB-C type cable to USB0 connector on the board. Then, turn-on the board and run the next command in terminal of build directory: uuu -b emmc_all imx-boot-imx8ulpevk-sd.bin-flash_singleboot_m33 imx-image-multimedia-imx8ulpevk.wic Now, power-off the board, change the boot mode to single boot-eMMC and power it on to test it. Test MQS1 in i.MX8ULP. To test MQS1 it is needed to change the device tree we created, we can do it with the next commands in U-boot: u-boot=> setenv fdtfile imx8ulp-evk-mqs.dtb u-boot=> saveenv u-boot=> boot Now we can test MQS1 on i.MX8ULP EVK, let's confirm that the clock is active in MQS module with the next command: $ cat /sys/kernel/debug/clk/clk_summary -n As you can see mqs1_sel is active and running at 24576000 Hz: And the card appears if we run the next command: $ aplay -l To play audio through MQS we can do it as any sound card: $ speaker-test -D sysdefault:CARD=imxsimplemqs -c 2 -f 48000 -F S16_LE -t pink -P 3 The signal should look like this in the pin output: And like this after a filter, for example the filter used in i.MX93 EVK.   With this post we have been able check the general operation of MQS, configure and compile the image with the required changes to enable MQS1 on EVK board and measure the output on the board. There is a considerable limitation on EVK board since we cannot test left and right outputs without intervene the base board, but this can be helpful as a reference to who would like to use this audio output on i.MX8ULP processor. Best regards. References. Yocto Project customization guide - NXP Community How to add a new layer and a new recipe in Yocto - NXP Community Flashing Linux BSP using UUU - NXP.  i.MX8ULP reference manual. Embedded Linux Projects Using Yocto Project Cookbook.
View full article
The following steps allow to make use of device tree overlay files, a definition of device tree overlay provided by kernel.org is the next:  "A Devicetree’s overlay purpose is to modify the kernel’s live tree, and have the modification affecting the state of the kernel in a way that is reflecting the changes. Since the kernel mainly deals with devices, any new device node that result in an active device should have it created while if the device node is either disabled or removed all together, the affected device should be deregistered." Knowing that, in this post will be used as an example the baseboard "i.MX 93 EVK" and will be added with device tree overlay an LVDS panel, adding an automatic detection from u-boot, and will be used a host with linux version Ubuntu 20.04.2. Note: It only works for linux kernel version 6.6.3-nanbield onward. Linux device-tree overlay from linux-imx   This section explains all about device tree overlay compilation and building, to create a .dtso file, the equivalent of .dts for overlays, adding some difference between them, using as base the linux-imx repository. It can be downloaded from the following repository:   git clone https://github.com/nxp-imx/linux-imx.git -b <branch version>   Branch version used by this post "lf-6.6.3-1.0.0". Device tree source overlay (.dtso)    It can be similar to a device tree source (.dts) but it had little difference between them, there are some difference in the next list: There's another type of files to be included, if is used pinmux it's necessary adding it with "#include "imx93-pinfunc.h"" and libraries from dt-bindings, it depends on the type of device tree to implement "#include <dt-bindings/<library>>" At initialization it needs to add: "/dts-v1/;"  "/plugin/;" Addition of "fragment" nodes, it allow override parts of a device tree,  it can be a specific node or create a new node. following structure it's the structure of a fragment:   { /* ignored properties by the overlay */ fragment@0 { /* first child node */ target=<phandle>; /* phandle target of the overlay */ or target-path="/path"; /* target path of the overlay */ __overlay__ { property-a; /* add property-a to the target */ node-a { /* add to an existing, or create a node-a */ ... }; }; } fragment@1 { /* second child node */ ... }; /* more fragments follow */ }   kernel.org Overlays can't delete a property or a node when it's applied, so can't be used "/delete-node/" nor "/delete-prop/", but it can be added to the node "status = "disabled";" to disable it.  Using as an example the file imx93-11x11-evk-boe-wxga-lvds-panel.dts located in the previous repository file direction <linux-imx path>/arch/arm64/boot/dts/freescale/ using it as a base tree:   // SPDX-License-Identifier: (GPL-2.0+ OR MIT) /* * Copyright 2022 NXP */ #include "imx93-11x11-evk.dts" / { lvds_backlight: lvds_backlight { compatible = "pwm-backlight"; pwms = <&adp5585pwm 0 100000 0>; enable-gpios = <&adp5585gpio 8 GPIO_ACTIVE_HIGH>; power-supply = <&reg_vdd_12v>; status = "okay"; brightness-levels = < 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100>; default-brightness-level = <80>; }; ... }; ... &adv7535 { status = "disabled"; }; ...   imx93-11x11-evk-boe-wxga-lvds-panel.dts Using the previous points and making use of fragments, if we want adapt the node lvds_backlight as fragment, it will be  added in the section of overlay, and adding it to a target-path "/":   #include <dt-bindings/interrupt-controller/irq.h> #include "imx93-pinfunc.h" #include <dt-bindings/gpio/gpio.h> /dts-v1/; /plugin/; / { fragment@0 { target-path = "/"; __overlay__ { lvds_backlight: lvds_backlight { compatible = "pwm-backlight"; pwms = <&adp5585pwm 0 100000 0>; enable-gpios = <&adp5585gpio 8 GPIO_ACTIVE_HIGH>; power-supply = <&reg_vdd_12v>; status = "okay"; brightness-levels = < 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100>; default-brightness-level = <80>; }; }; }; ... };   imx93-11x11-evk-test-lvds-panel.dtso In the case of adding a property to an existing node, it will look in the following way using as example the node adv7535.   ... / { ... fragment@2 { target = <&adv7535>; __overlay__ { status = "disabled"; }; }; ... };   imx93-11x11-evk-boe-wxga-lvds-panel.dts At the end of this post, will be attach the complete file used for LVDS panel named as imx93-11x11-evk-test-lvds-panel.dtso Build device tree blob for overlay (dtbo)   To compile the previous .dtso it's necessary to include it to linux-imx repository, linux device tree overlay was included in BSP from version 6.6.3-nanbield onward in Makefile, so it's only necessary adding it as files to be compiled as .dtso, at the end of the post will be a patch file named as linux-imx-makefile.patch to add LVDS-panel to Makefile from branch lf-6.6.3-1.0.0 Add previously file imx93-11x11-evk-test-lvds-panel.dtso to path <linux-imx path>/arch/arm64/boot/dts/freescale/ Add imx93-11x11-evk-test-lvds-panel.dtso as file to be compiled in Makefile, it is located in the next path <linux-imx path>/arch/arm64/boot/dts/freescale/Makefile, it can be added with the next sentence format: <overlay without extension>-dtbs := <file to be overlayed>.dtb <overlay>.dtbo Example of how to add LVDS panel to makefile  imx93-11x11-evk-test-lvds-panel-dtbs := imx93-11x11-evk.dtb imx93-11x11-evk-test-lvds-panel.dtbo Makefile From main path, make the configuration to be compiled with the following bash command: $ cd <linux-imx path>/ $ make -j$(nproc --all) ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- imx_v8_defconfig​ Compile overlay to use $ make -j $(nproc --all) ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- freescale/<overlay>.dtbo​ as example for LVDS panel $ make -j $(nproc --all) ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- freescale/imx93-11x11-evk-test-lvds-panel.dtbo It will compile the device tree blob overlay to use. Copy .dtbo generated in memory used by i.MX 93, it can be sending it from scp. scp ./​<overlay>.dtbo​ root@<ip>:/run/media/<memory section used> u-boot   This section explain the procedure to load a device tree overlay, it will be from u-boot explaining commands used and using the LVDS panel as an example. Before applying overlay   Before applying, it's necessary had a device tree loaded so looking around in the process of booting in a i.MX 93 from u-boot, this process is defined by the enviroment variable "bsp_bootcmd" that calls the variable mmcboot, and looking what does these variables, it can be look in the following sentence:    bsp_bootcmd=echo Running BSP bootcmd ...; mmc dev ${mmcdev}; if mmc rescan; then if run loadbootscript; then run bootscript; else if test ${sec_boot} = yes; then if run loadcntr; then run mmcboot; else run netboot; fi; else if run loadimage; then run mmcboot; else run netboot; fi; fi; fi; fi; mmcboot=echo Booting from mmc ...; run mmcargs; if test ${sec_boot} = yes; then if run auth_os; then run boot_os; else echo ERR: failed to authenticate; fi; else if test ${boot_fit} = yes || test ${boot_fit} = try; then bootm ${loadaddr}; else if run loadfdt; then run boot_os; else echo WARN: Cannot load the DT; fi; fi;fi;   but reducing it in a normal situation, ignoring if else case and echoes, it can be simplify to:   mmc dev ${mmcdev}; run loadimage; run mmcargs; run loadfdt; run boot_os;   the device tree is load is in the section "run loadfdt" with fatload in his definition:   loadfdt=fatload mmc ${mmcdev}:${mmcpart} ${fdt_addr_r} ${fdtfile}   So, it's necessary to applying device tree overlay after "run loadfdt". How to apply an overlay   To load correctly an overlay it's necessary to following some steps: Load flattened device tree (fdt). (executed by loadfdt) Configure fdt address.  In some cases it's necessary to expand fdt memory size Load overlay Apply overlay The full sentence to apply it, it's the following u-boot command:   u-boot=> setexpr fdtovaddr ${fdt_addr} + 0xF0000; setexpr fdt_buffer 16384; fdt addr ${fdt_addr} && fdt resize ${fdt_buffer}; fatload mmc ${mmcdev}:${mmcpart} ${fdtovaddr} <overlay>.dtbo && fdt apply ${fdtovaddr};   First of all, setexpr it's just to create a new variable, in this case these variable is an integer. Spliting the previously command we can found the steps to applying it. "fdt addr ${fdt_addr};" used to configure fdt address, and point to the space of memory previously charged. "fdt resize ${fdt_buffer};" expand fdt memory size, is used as a value 16384 just to get the enough space to charge dtbo, this number was related with 2 14 "fatload mmc ${mmcdev}:${mmcpart} ${fdtovaddr} <overlay>.dtbo" Load device tree overlay using fdovaddr, that is fdt_addr adding an offset of memory space.  "fdt apply ${fdtovaddr};" apply device tree overlay Remembering about load overlay needs to be executed after loadfdt, it's possible to save the previous command to a variable and executing it after loadfdt with setexpr, in this case using as example lvds test.   u-boot=> setenv loadoverlay "setexpr fdtovaddr ${fdt_addr} + 0xF0000; setexpr fdt_buffer 16384; fdt addr $\{fdt_addr\} && fdt resize $\{fdt_buffer\}; fatload mmc $\{mmcdev\}:$\{mmcpart\} $\{fdtovaddr\} imx93-11x11-evk-test-lvds-panel.dtbo && fdt apply $\{fdtovaddr\};"   and modifying mmcboot with loadoverlay after loadfdt   u-boot=> setenv mmcboot "run mmcargs; run loadfdt; run loadoverlay; run boot_os;"   to save the environment variables created, it can be saved from u-boot wit the following command.   u-boot=> saveenv   At the end, boot imx93   u-boot=> boot   The LVDS panel should be working using the original dtb (imx93-11x11-evk.dtb) applied the overlay. Automatize u-boot LVDS Panel   This section explain how can be automatize the u-boot load overlay using an LVDS panel, it can vary depending the device to used for, the method used is detecting it in u-boot initialization and if found any device it will generate an environment variable. All the steps was using as a base uboot-imx repository, it can be downloaded from the following repository, at the end of this post will be a patch with the changes.   git clone https://github.com/nxp-imx/uboot-imx.git -b <branch version>   Branch version used "lf-6.6.3-1.0.0". Base   Knowing more about LVDS Panel used by imx93 it's really hard know more information about registers, so in this example will be limited to detect that is connected the address to a corresponding bus from touch controller.  To know i2c address and bus used by LVDS panel it was used searching it from the original device tree in the next section:   &lpi2c1 { exc80h60: touch@2a { compatible = "eeti,exc80h60"; reg = <0x2a>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_ctp_int>; /* * Need to do hardware rework here: * remove R131, short R181 */ interrupt-parent = <&gpio2>; interrupts = <21 IRQ_TYPE_LEVEL_LOW>; reset-gpios = <&pcal6524 17 GPIO_ACTIVE_HIGH>; status = "okay"; }; };   imx93-11x11-evk-boe-wxga-lvds-panel.dts Previous node is related with touch controller from LVDS using lpi2c1, the first channel of i2c corresponding to i2c bus 0, and the register used express the address used to be detected by device tree, in this case was the address 0x2A. u-boot generating a trigger   About how it can be detected touch controller from u-boot, this procedure use a function named as "board_late_init", it can be found by his definition from u-boot readme:   Board initialization settings: ------------------------------ During Initialization u-boot calls a number of board specific functions to allow the preparation of board specific prerequisites, e.g. pin setup before drivers are initialized. To enable these callbacks the following configuration macros have to be defined. Currently this is architecture specific, so please check arch/your_architecture/lib/board.c typically in board_init_f() and board_init_r(). - CONFIG_BOARD_EARLY_INIT_F: Call board_early_init_f() - CONFIG_BOARD_EARLY_INIT_R: Call board_early_init_r() - CONFIG_BOARD_LATE_INIT: Call board_late_init()   u-boot README In the case of i.MX 93 this function can be found in the next path <u-boot path>/board/freescale/imx93_evk/imx93_evk.c. Using the library included, "uclass.h", it will create a function that, if detect in the bus 0 (LVDS i2c bus) the address 0x2A (i2c LVDS address), it will create an environment variable with the overlay used, it can be set with the function env_set(<String with the name of the variable>, <String with the content of the variable>), the following function can detect and create the environment variable mentioned, creating it with the name "device-tree-overlay" with the content "lvds-panel".   #define LVDS_TOUCH_I2C_BUS 0 #define LVDS_TOUCH_I2C_ADDR 0x2A static void detect_display_connected(void) { struct udevice *bus = NULL; struct udevice *i2c_dev = NULL; int ret; ret = uclass_get_device_by_seq(UCLASS_I2C, LVDS_TOUCH_I2C_BUS, &bus); if (ret) { printf("%s: Can't find bus\n", __func__); } else { ret = dm_i2c_probe(bus, LVDS_TOUCH_I2C_ADDR, 0, &i2c_dev); if (ret) { printf("%s: Can't find device id=0x%x\n", __func__, LVDS_TOUCH_I2C_ADDR); } else { env_set("device-tree-overlay", "lvds-panel"); } } }   imx93_evk.c At the end, add this function to the previously mention, named as board_late_init, in the section CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG, like the following snipped from code:   int board_late_init(void) { #ifdef CONFIG_ENV_IS_IN_MMC board_late_mmc_env_init(); #endif env_set("sec_boot", "no"); #ifdef CONFIG_AHAB_BOOT env_set("sec_boot", "yes"); #endif #ifdef CONFIG_ENV_VARS_UBOOT_RUNTIME_CONFIG env_set("board_name", "11X11_EVK"); env_set("board_rev", "iMX93"); detect_display_connected(); #endif return 0; }   imx93_evk.c Now, when it's starting u-boot after flashing, it will generate the environment variable as trigger if something it's connected with that i2c address, else it doesn't do anything. u-boot applying device tree overlay through event   As was explained in the section "How to apply device tree overlay", applying the device tree overlay automatically after configure the trigger it's easy, just adding an if/else case for this example, it can be more ways to applying it, even it's possible adding more of one device tree overlay, but in this example will load one.  Using u-boot command "test -e <environment variable>" it will detect if exist this environment variable, adding it to an if/else sentence it can create the event and applying the overlay if was detected or not, for this solution will be added this if/else as input if exists loadoverlay variable with the following structure:   u-boot=> if test -e ${device-tree-overlay}; then <case exists device-tree-overlay variable> else <case doesn't exists device-tree-overlay variable>; fi;   adding it to loadoverlay, it will be written like the following command:   u-boot=> setenv loadoverlay "if test -e ${device-tree-overlay}; then setexpr fdtovaddr ${fdt_addr} + 0xF0000; setexpr fdt_buffer 16384; fdt addr ${fdt_addr} && fdt resize $\{fdt_buffer\}; fatload mmc ${mmcdev}:${mmcpart} $\{fdtovaddr\} imx93-11x11-evk-test-lvds-panel.dtbo; fdt apply $\{fdtovaddr\} ; else echo no overlay; fi;"   A no recommended method it's that it can be saved the environment, and changing mmcboot variable with the following command:   u-boot=> setenv mmcboot "run mmcargs; run loadfdt; run loadoverlay; run boot_os;"; saveenv;   The problem about just saving it, it still necessary compile u-boot to load auto-detection of LVDS panel and flashing, another way to add the event trigger, it's adding it to u-boot as initial environment variable, it can be added in the header file of imx93, it is located in the next path <u-boot path>/include/configs/imx93_evk.h, line number 60, it can be added with the same string but it's recommended follow the same structure, like the following definition:   /* Initial environment variables */ #define CFG_EXTRA_ENV_SETTINGS \ ... "loadoverlay=echo loading overlays from mmc ...; " \ "if test -e ${device-tree-overlay}; then " \ "setexpr fdtovaddr ${fdt_addr} + 0xF0000; " \ "setexpr fdt_buffer 16384; " \ "fdt addr ${fdt_addr} && fdt resize ${fdt_buffer}; " \ "fatload mmc ${mmcdev}:${mmcpart} ${fdtovaddr} imx93-11x11-evk-test-lvds-panel.dtbo && fdt apply ${fdtovaddr}; " \ "else " \ "echo no overlay; " \ "fi;\0" \ ...   imx93_evk.h it also it's necessary to change mmcboot environment variable adding loadoverlay after executing loadfdt.    /* Initial environment variables */ #define CFG_EXTRA_ENV_SETTINGS \ .. "mmcboot=echo Booting from mmc ...; " \ "run mmcargs; " \ "if test ${sec_boot} = yes; then " \ "if run auth_os; then " \ "run run boot_os; " \ "else " \ "echo ERR: failed to authenticate; " \ "fi; " \ "else " \ "if test ${boot_fit} = yes || test ${boot_fit} = try; then " \ "bootm ${loadaddr}; " \ "else " \ "if run loadfdt; then " \ "run loadoverlay; " \ "run boot_os; " \ "else " \ "echo WARN: Cannot load the DT; " \ "fi; " \ "fi;" \ "fi;\0" \ ...   imx93_evk.h To build u-boot, copy the following commands in main path from u-boot   $ cd <u-boot path> $ make -j $(nproc --all) clean PLAT=imx93 CROSS_COMPILE=aarch64-linux-gnu- $ make -j $(nproc --all) ARCH=arm CROSS_COMPILE=aarch64-linux-gnu- imx93_11x11_evk_defconfig $ make -j $(nproc --all) PLAT=imx93 CROSS_COMPILE=aarch64-linux-gnu-   generating the files u-boot.bin and u-boot-spl.bin located in <uboot-imx path>/ and <uboot-imx path>/spl Build imx-boot image using imx-mkimage   To build the binary necessary to flash to iMX 93 EVK it's necessary build a file named as flash.bin, it can building using the next repository using the branch used for this example:    $ git clone https://github.com/nxp-imx/imx-mkimage.git -b lf-6.6.3_1.0.0   to build imx-boot image it's necessary adding some files to the path <imx-mkimage path>/iMX93, including 2 generated by u-boot, u-boot.bin and u-boot-spl.bin, move these files to iMX93 directory.   $ cp <uboot-imx path>/u-boot.bin <uboot-imx path>/spl/u-boot-spl.bin <imx-mkimage path>/iMX93/   follow the steps from imx linux users guide section 4.5.13 and imx linux release notes section 1.2 to build flash.bin, as an example of compile, there's the steps to compile for imx93. Get mx93a1-ahab-container.img $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-sentinel-0.11.bin $ chmod +x firmware-sentinel-0.11.bin $ ./firmware-sentinel-0.11.bin $ cp firmware-sentinel-0.11/mx93a1-ahab-container.img <imx-mkimage path>/iMX93/​ Get lpddr4_imem_1d_v202201.bin, lpddr4_dmem_2d_v202201.bin, lpddr4_imem_1d_v202201.bin and lpddr4_imem_2d_v202201.bin $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.23.bin $ chmod +x firmware-imx-8.23.bin $ ./firmware-imx-8.23.bin $ cp firmware-imx-8.23/firmware/ddr/synopsys/lpddr4_dmem_1d_v202201.bin firmware-imx-8.23/firmware/ddr/synopsys/lpddr4_dmem_2d_v202201.bin firmware-imx-8.23/firmware/ddr/synopsys/lpddr4_imem_1d_v202201.bin firmware-imx-8.23/firmware/ddr/synopsys/lpddr4_imem_2d_v202201.bin <imx-mkimage path>/iMX93/​ Get bl31.bin $ git clone https://github.com/nxp-imx/imx-atf.git -b lf-6.6.3-1.0.0 $ cd imx-atf $ make -j $(nproc --all) PLAT=imx93 CROSS_COMPILE=aarch64-linux-gnu- $ cp <imx-atf path>/build/imx93/release/bl31.bin <imx-mkimage path>/iMX93​ Compile flash.bin from imx-mkimage $ cd <imx-mkimage path>/ $ make SOC=iMX9 REV=A1 flash_singleboot​ it will generate the binary flash.bin located in the path <imx-mkimage path>/iMX93/flash.bin. Flashing u-boot   Flashing just u-boot image using flash.bin, will be used uuu.exe, it can be downloaded from the his repositroy, try using the most recent version taged as "Latest"    https://github.com/nxp-imx/mfgtools/releases   make sure is using i.MX 93 EVK in boot mode download and connect it to your host from download USB port, using uuu.exe run the next code:   .\uuu.exe -b emmc .\flash.bin   or it can be flashed the full image with flash.bin binary.   .\uuu.exe -b emmc_all .\flash.bin ..\uuu\imx-image-full-imx93evk.wic   after that, starting be will using the created u-boot environment. Result   Inside u-boot, when it's connected the LVDS panel, it will create the variable named "device-tree-overlay" and will be charged automatically LVDS panel overlay, enabling it, if not it will working normally using DSI as output. Note: Ensure to have imx93-11x11-evk-test-lvds-panel.dtbo in memory. Reference   Device tree overlay: https://docs.kernel.org/devicetree/overlay-notes.html  
View full article
On this tutorial we will review the implementation of Flutter on the i.MX8MP using the Linux Desktop Image. Please find more information about Flutter using the following link: Flutter: Option to create GUIs for Embedded System... - NXP Community Requirements: Evaluation Kit for the i.MX 8M Plus Applications Processor. (i.MX 8M Plus Evaluation Kit | NXP Semiconductors) NXP Desktop Image for i.MX 8M Plus (GitHub - nxp-imx/meta-nxp-desktop at lf-6.1.1-1.0.0-langdale) Note: This tutorial is based on the NXP Desktop Image with Yocto version 6.1.1 – Langdale. Steps: 1. First, run commands to update packages. $ sudo apt update $ sudo apt upgrade 2. Install Flutter for Linux using the following command. $ sudo snap install flutter --classic 3. Run the command to verify the correct installation. $ flutter doctor With this command you will find information about the installation. The important part for our purpose is the parameter "Linux toolchain - develop for Linux desktop". 4. Run the command “flutter create .” to create a flutter project, this framework will create different folders and files used to develop the application.  $ cd Documents $ mkdir flutter_hello $ cd flutter_hello $ flutter create .​ 5. Finally, you can run the “hello world” application using: $ flutter run Verify the program behavior incrementing the number displayed on the window.  
View full article
  Test environment   i.MX8MP EVK LVDS0 LVDS-HDMI  bridge(it6263) Uboot2022, Uboot2023 Background   Some customers need show logo using LVDS panel. Current BSP doesn't support LVDS driver in Uboot. This patch provides i.MX8MPlus LVDS driver support in Uboot. If you want to connect it to LVDS panel , you need port your lvds panel driver like  simple-panel.c   Update [2022.9.19] Verify on L5.15.32_2.0.0  0001-L5.15.32-Add-i.MX8MP-LVDS-driver-in-uboot 'probe device is failed, ret -2, probe video device failed, ret -19' is caused by below code. It has been merged in attachment. // /* Only handle devices that have a valid ofnode */ // if (dev_has_ofnode(dev) && !(dev->driver->flags & DM_FLAG_IGNORE_DEFAULT_CLKS)) { // /* // * Process 'assigned-{clocks/clock-parents/clock-rates}' // * properties // */ // ret = clk_set_defaults(dev, CLK_DEFAULTS_PRE); // if (ret) // goto fail; // }   [2023.3.14] Verify on L5.15.71 0001-L5.15.71-Add-i.MX8MP-LVDS-support-in-uboot   [2023.9.12] For some panel with low DE, you need uncomment CTRL_INV_DE line and set this bit to 1. #include <linux/string.h> @@ -110,9 +111,8 @@ static void lcdifv3_set_mode(struct lcdifv3_priv *priv, writel(CTRL_INV_HS, (ulong)(priv->reg_base + LCDIFV3_CTRL_SET)); /* SEC MIPI DSI specific */ - writel(CTRL_INV_PXCK, (ulong)(priv->reg_base + LCDIFV3_CTRL_CLR)); - writel(CTRL_INV_DE, (ulong)(priv->reg_base + LCDIFV3_CTRL_CLR)); - + //writel(CTRL_INV_PXCK, (ulong)(priv->reg_base + LCDIFV3_CTRL_CLR)); + //writel(CTRL_INV_DE, (ulong)(priv->reg_base + LCDIFV3_CTRL_CLR)); }       [2024.5.15] If you are uing simple-panel.c, need use below patch to set display timing from panel to lcdif controller. diff --git a/drivers/video/simple_panel.c b/drivers/video/simple_panel.c index f9281d5e83..692c96dcaa 100644 --- a/drivers/video/simple_panel.c +++ b/drivers/video/simple_panel.c @@ -18,12 +18,27 @@ struct simple_panel_priv { struct gpio_desc enable; }; +/* define your panel timing here and + * copy it in simple_panel_get_display_timing */ +static const struct display_timing boe_ev121wxm_n10_1850_timing = { + .pixelclock.typ = 71143000, + .hactive.typ = 1280, + .hfront_porch.typ = 32, + .hback_porch.typ = 80, + .hsync_len.typ = 48, + .vactive.typ = 800, + .vfront_porch.typ = 6, + .vback_porch.typ = 14, + .vsync_len.typ = 3, +}; + @@ -100,10 +121,18 @@ static int simple_panel_probe(struct udevice *dev) return 0; } +static int simple_panel_get_display_timing(struct udevice *dev, + struct display_timing *timings) +{ + memcpy(timings, &boe_ev121wxm_n10_1850_timing, sizeof(*timings)); + + return 0; +} static const struct panel_ops simple_panel_ops = { .enable_backlight = simple_panel_enable_backlight, .set_backlight = simple_panel_set_backlight, + .get_display_timing = simple_panel_get_display_timing, }; static const struct udevice_id simple_panel_ids[] = { @@ -115,6 +144,7 @@ static const struct udevice_id simple_panel_ids[] = { { .compatible = "lg,lb070wv8" }, { .compatible = "sharp,lq123p1jx31" }, { .compatible = "boe,nv101wxmn51" }, + { .compatible = "boe,ev121wxm-n10-1850" }, { } };   [2024.7.23] Update patch for L6.6.23(Uboot2023)
View full article