Hey everyone! With the iMX8MM EVK, you also get an IR receiver LED interfaced with one of the GPIOs. Through this article today, I will demonstrate how to enable Infrared Receiver on the iMX8MM EVK so that data sent from the IR transmitter LEDs can be received and decoded on the iMX8MM EVK. Hardware used : iMX8MM EVK - i.MX 8M Mini Evaluation Kit | NXP Semiconductors Arduino Uno board IR TX module Arduino interfaced with IR TX will send IR messages to iMX8MM interfaced with IR RX LED Hardware connections: IR TX Module         <---->          Arduino Uno GND                          -                     GND 3.3V                          -                     3.3V DAT                           -                     D3 IR transmitter LED connected to Arduino Uno -- Kernel configurations needed: Linux Kernel Configurations Copy the kernel 'Image' built with the above changes and the IR decoder modules for the protocol you want to decode. All the ko modules are present i.e ir-rc5-decoder.ko for rc5 IR decoding in this folder after building: LIRC drivers Boot linux with the default dtb[imx8mm-evk.dtb] and the newly copied kernel 'Image' that you uploaded on the board.   At boot-up rc_register_device is called from drivers/media/rc/rc-main.c. A /dev/lirc0 node will also be created as a result of in-built driver loading. You can verify this by executing: lirc device node   On iM8MM, The IR receiver is connected to GPIO1_13. drivers/media/rc/gpio-ir-recv.c is responsible to configure this GPIO using the dts entry present in  arch/arm64/boot/dts/freescale/imx8mm-evk.dtsi   Device tree changes gpio_ir_recv_probe will be called from drivers/media/rc/gpio-ir-recv.c.   At linux prompt, you can verify the gpio configuration using sysfs: IR GPIO Now insert the NEC and RC5 decoder modules. This gives the kernel ability to be able to decode the   NEC and RC5 IR protocols. LIRC Decoder Next, we need a program that utilizes the decoder driver to start decoding the IR signals coming onto the IR Receiver of iMX8MM EVK.   Some example invocations of the user-space binary we have built for the above purpose: RC5 Decoder RC6 Decoder NEC Decoder   ir_recv accepts 2 arguments:- 1st argument - protocol to enable 2nd argument - the remote-control device created in the /sys/class/rc example - /sys/class/rc/rc0 Note - Not to be confused with the protocols rc5 or rc6. The 2nd argument is not the name of the protocol ir_recv utility that we have built will open the /dev/lirc0 device and make an ioctl call LIRC_SET_REC_MODE to set the LIRC driver in Recording mode. These ioctls are handled in drivers/media/rc/lirc_dev.c in the kernel source code. So that whenever you run the ir_recv binary, it polls for the IR protocol scan code and prints it if successfully decoded. Attaching the ir_recv executable and the source code with this article for you to test and tweak. Please let me know if you have any follow-up questions. I would be happy to indulge. That's all I have for today. Thank you for your time!  

Overview   This document intends to provide one reference how to emulate i.MX8QM 1.3GHz part running on i.MX8QM MEK with 1.6GHz part based on i.MX Linux BSP release.   You can find i.MX8QM/QP processors datasheet on NXP web: i.MX 8QuadMax 1.3GHz Automotive and Infotainment Applications Processors; i.MX 8QuadPlus 1.3GHz Automotive and Infotainment Applications Processors; i.MX 8QuadPlus Industrial Applications Processors Data Sheet; i.MX 8QuadMax Industrial Applications Processors Data Sheet;   Key differences between 1.3GHz part and 1.6GHz part is as follows: Key Differences 1.6GHz part 1.3GHz part 8QM/8QP A72 core max frequency 1600MHz 1296MHz 8QM GPU max frequency core 800MHz  shader 1000MHz core 650MHz shader 700MHz 8QM VDD_GPU mode Overdrive mode Remove overdrive mode, only nominal 8QM VDD_GPU nominal operation range Min 0.95V Typ 1.0 V Max 1.1V Min 0.98V Typ 1.03125V Max 1.14V   Software Changes   Since Linux 6.6.23_2.0.0 BSP release, i.MX8QM/8QP 1.3GHz part is supported into i.MX Linux release by identifying the fuse of 1.3GHz part and configuring frequency and voltage automatically. If you have i.MX8QM MEK board with 1.6GHz part, before revision E, you can apply software changes to emulate 1.3GHz part configurations explicitly. The following software reference patches are built based on Linux 6.6.52-2.2.0 release: Component Patch Name Description Linux Kernel 0001-arm64-dts-imx8qm-remove-A72-core-1.6GHz-operating-po.patch Used to remove Cortex-A72 core 1.6GHz operating-points 0002-arm64-dts-imx8qm-set-GPU-operating-points-at-nominal.patch Used to remove GPU overdrive operating-points and set GPU core frequency as 650MHz, GPU shader frequency as 700MHz. SCFW 0001-Increase-VDD-of-GPU.patch Used to increase GPU voltage ATF 0001-plat-imx8-make-ATF-kick-off-A72-core-freq-at-1.3GHz.patch Used to kickoff A72 core and set its frequency as 1.3GHz in ATF   Validation Test Apply patch into Linux kernel, SCFW porting kit, ATF, follow 6.6.52_2.2.0 release document(www.nxp.com/design/design-center/software/embedded-software/i-mx-software/embedded-linux-for-i-mx-applications-processors:IMXLINUX) to build and deploy image.     After Linux OS boot up,  run below command to check A72 and GPU frequency,  for example: #cat /sys/kernel/debug/gc/clk gpu0 mc clock: 647981058 HZ. gpu0 sh clock: 695997687 HZ. gpu1 mc clock: 647990370 HZ. gpu1 sh clock: 695987994 HZ   #cat /sys/devices/system/cpu/cpu4/cpufreq/cpuinfo_max_freq 1296000   Measure VDD_GPU voltage from i.MX8QM MEK board TP53 and TP42

Quickly develop and deploy IoT applications with Clea on your NXP device. This guide walks you through setting up Clea, managing devices remotely, and leveraging AI-powered telemetry for industrial applications.

The doc gives an introduction about how to get and run the watch-face APK on i.MX.8ULP watch board based on Android 14.0.0_1.0.0. 1. Get source code Get the shell script and related patches from the attachment at the end of the article. Run Watchface_setup.sh. Watchface_setup.sh will download all the needed gits codes. combine with them and apply patches automatically. You need to clone the gits manually if network access is not good. 2. Build the project The project is in the sub-directory named "KWART_Kid_Launcher". Then you can build it either in Android studio or Android SDK. Android studio Open the project in Android studio and build it like regular. Android SDK Copy KWART_Kid_Launcher/ into vendor/nxp-opensource/fsl_imx_demo/ Add the following into the end of device/nxp/imx8ulp/watch_8ulp/watch_8ulp.mk. PRODUCT_PACKAGES += \ KWARTLauncher Rebuild the SDK. Please refer to Android User's Guide for more details about SDK building. make -j4 2>&1 | tee make.log 3. Install the APK Install the APK Android studio Run the app like regular. Android SDK Reflash the SDK images and the app will occur after boot finishes. Then you will find the following APP.  

Introduction. i.MX8ULP boot partition is handled by imx-boot image as the 8M family processors and i.MX 9 series processors, keeping the usage of imx-mkimage and UUU tools for updating the firmware to the boot media. The difference is that this processor is focus on working over Cortex-M, starting from boot which is handled by uPower ROM, it can boot Application Domain or Real Time Domain firmware images meanwhile other processors boot is less flexible, focusing on Cortex-A. This guide will explore this flexibility and it's intended for board users that test prebuilt images, want to get started with imx-boot customization, want to run SDK/Standalone examples on Cortex-M or need to perform recovery to their boards. 1. Hardware Setup. Retrieve your silicon revision from the TOP marking; BUILD A1 in this case. Identify your board in the base board silkscreen, you can work with MCIMX8ULP-EVK or MCIMX8ULP-EVK9. Connect 5V power source to P1. Connect USB type-A to type-C to USB0 J15. Connect USB type-A to type-micro-B to DEBUG J17.   2. Firmware Images Gathering. $ cd ~/Projects/ $ git clone https://github.com/nxp-imx/imx-mkimage.git Make sure that you use all images from the same release, this document uses first release for IMX8ULP; LF6.1.22. Download Sentinel Firmware retrieving the version from Release Notes. After installation copy the firmware for the silicon revision owned, mx8ulpa1 is used for REV A1. $ cd ~/Projects/ $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-sentinel-0.10.bin $ chmod a+x firmware-sentinel-0.10.bin $ ./firmware-sentinel-0.10.bin $ cp firmware-sentinel-0.10/mx8ulpa1-ahab-container.img ~/Projects/imx-mkimage/iMX8ULP/ Remaining firmware will be obtained from a Yocto build, is the method that requires less steps. Make sure that the MACHINE variable matches your board. $ mkdir ~/Projects/Yocto-BSP-i.MX $ cd ~/Projects/Yocto-BSP-i.MX/ $ repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-mickledore -m imx-6.1.22-2.0.0.xml $ repo sync $ MACHINE=imx8ulp-lpddr4-evk DISTRO=fsl-imx-xwayland source ./imx-setup-release.sh -b i.MX8ULPEVK $ bitbake core-image-minimal $ cd tmp/deploy/images/imx8ulp-lpddr4-evk/ $ cp bl31-imx8ulp.bin ~/Projects/imx-mkimage/iMX8ULP/bl31.bin $ cp u-boot-imx8ulp-lpddr4-evk.bin-sd ~/Projects/imx-mkimage/iMX8ULP/u-boot.bin $ cp u-boot-spl.bin-imx8ulp-lpddr4-evk-sd ~/Projects/imx-mkimage/iMX8ULP/u-boot-spl.bin $ cp imx-boot-tools/upower.bin ~/Projects/imx-mkimage/iMX8ULP/upower.bin Cortex-M firmware can be built with VS Code in Windows or by Standalone build in Linux, make sure that you have the GNU toolchain installed. Build the Power Mode Switch demo, is easier to work with it later in this document we will explore other type of demos. $ cd ~/Projects/ $ cp ~/Public/EVK-MIMX8ULP-power_mode_switch.zip . $ unzip EVK-MIMX8ULP-power_mode_switch.zip # Rename directory for this example, you can skip and use the default name. $ mv power_mode_switch/ Standalone-IMX8ULP-Power-Switch $ cd Standalone-IMX8ULP-Power-Switch/ $ ls $ chmod a+x *.sh $ ./clean.sh $ export ARMGCC_DIR=/opt/arm-gnu-toolchain-12.3.rel1-x86_64-arm-none-eabi/ # Adding a custom line (607) to print a custom message. # freq = CLOCK_GetFreq(kCLOCK_Cm33CorePlatClk); # PRINTF("\r\n#################### Standalone Built 02/21 ####################\n\r\n"); # PRINTF("\r\n#################### Power Mode Switch Task ####################\n\r\n"); $ nano source/power_mode_switch.c $ ./build_release.sh $ cp release/sdk20-app.bin ~/Projects/imx-mkimage/iMX8ULP/m33_image.bin $ ./clean.sh 3. Build and flash imx-boot firmware for Singleboot M33. This test will use Single boot – eMMC 1000_0000 pin config mode. Singleboot_M33 image stores AP FW and RT FW in eMMC, at boot time both cores work. $ cd ~/Projects/imx-mkimage/ $ make clean $ make SOC=iMX8ULP REV=A1 flash_singleboot_m33 $ cp iMX8ULP/flash.bin ~/Public/imx-boot.bin-flash_singleboot_m33 Set boot pins to 0100_0000 – Serial Download and power up the board. Flash the image using a Windows or Linux host through UUU tool. > uuu -b emmc .\imx-boot.bin-flash_singleboot_m33 Wait for UUU to print 'done' message for the command issued. 4. Test new imx-boot firmware. Set the boot pins to the config you build for and power up the board. Cortex-A output is sent through 3rd COM port and Cortex-M output through 4th. 5. Board running freertos_swtimer_cm33 and hello_world_cm33 demos. To run these demos build them through VS Code or Standalone build and copy them to imx-mkimage directory. $ cp <path to binary>/sdk20-app.bin ~/Projects/imx-mkimage/iMX8ULP/m33_image.bin $ cd ~/Projects/imx-mkimage/ $ make clean $ make SOC=iMX8ULP REV=A1 flash_singleboot_m33 $ cp iMX8ULP/flash.bin ~/Public/imx-boot.bin-flash_singleboot_m33 When this demos are running, they don't allow Cortex-A to get to U-boot, this is an issue when trying to flash new or recovery images, the board just reboots with the new FW but it's not written to eMMC, you can identify this situation when UUU prompts 100%, the command appears to hang and 'done' is not displayed. To flash a new firmware, IMX8ULP needs to boot from Serial Download pin config. Then run the script attached and go to step 4. > uuu .\uuu.auto 6. Running Dualboot demos for asynchronous operation. Dualboot are two images, AP FW which must be stored in eMMC and RT FW stored at FlexSPI0 NOR, at boot time both cores work. Boot is asynchronous and needs both images at the same time, this requires to flash two images at the same time, U-boot fastboot mode facilitates writing to eMMC while being able to use its console. Issue the following command at U-boot. => fastboot 0 Build the firmware images for A35-eMMC M33-NOR – 1000_0010* pin config. * You can also boot from LP mode – 1000_0001 pin config, this allows only M33 code to boot initially. $ make SOC=iMX8ULP REV=A1 flash_dualboot $ cp iMX8ULP/flash.bin ~/Public/imx-boot.bin-flash_dualboot $ make SOC=iMX8ULP REV=A1 flash_dualboot_m33 $ cp iMX8ULP/flash.bin ~/Public/imx-boot.bin-flash_dualboot_m33 > uuu -b emmc .\imx-boot.bin-flash_dualboot > uuu -b fat_write .\imx-boot.bin-flash_dualboot_m33 mmc 0:1 spi.bin => Ctrl + c => fatload mmc 0:1 ${loadaddr} spi.bin; setenv erase_unit 1000; setexpr erase_size ${filesize} + ${erase_unit}; setexpr erase_size ${erase_size} / ${erase_unit}; setexpr erase_size ${erase_size} * ${erase_unit}; sf probe 0:0; sf erase 0 ${erase_size} => sf write ${loadaddr} 0 ${filesize} Then go to step 4. Conclusion. This document explore all the boot configurations that feature the A35 storing its firmware in eMMC and M33 running its demo binary. Can help users that are looking to run demos on Cortex-M with their out-of-the-box board, continuing with them through the trial of different demos and boot modes to understand what are different outcomes, adapt the project in that way and develop the application over a template.

  Test Environment i.MX8MP EVK L6.6.52   Backgroud The default BSP will assign SAI3 and I2C3 to M7 when we use imx8mp-evk-rpmsg.dtb. If customer want to assign SAI3 and I2C3 to A53 and test audio in Linux while running M7 sdk with remoterpoc.   Test steps   1. Delete all of audio related code in SDK in below function. BOARD_BootClockRUN  BOARD_RdcInit 2. Modify Uboot   arch/arm/dts/imx8mp-evk-u-boot.dtsi   The RDC will assign SAI3, sdma3 and i2c3 to M7 when M7 start. So we need to delete these lines.      3. Add RDC config in ATF plat/imx/imx8m/imx8mp/imx8mp_bl31_setup.c  Assign SAI3, sdma3 and i2c3 to A53.    4.Modify imx8mp-evk-rpmsg.dts Delete rpmsg audio and i2c3. diff --git a/arch/arm64/boot/dts/freescale/imx8mp-evk-rpmsg-lpv.dts b/arch/arm64/boot/dts/freescale/imx8mp-evk-rpmsg-lpv.dts index e43c4dafdb88..4edc0cb71b1c 100644 --- a/arch/arm64/boot/dts/freescale/imx8mp-evk-rpmsg-lpv.dts +++ b/arch/arm64/boot/dts/freescale/imx8mp-evk-rpmsg-lpv.dts @@ -4,8 +4,3 @@ */ #include "imx8mp-evk-rpmsg.dts" - -&rpmsg_audio { - /delete-property/ fsl,enable-lpa; - /delete-property/ fsl,rpmsg-in; -}; diff --git a/arch/arm64/boot/dts/freescale/imx8mp-evk-rpmsg.dts b/arch/arm64/boot/dts/freescale/imx8mp-evk-rpmsg.dts index ddf5f76adc3b..75c9234d84b2 100644 --- a/arch/arm64/boot/dts/freescale/imx8mp-evk-rpmsg.dts +++ b/arch/arm64/boot/dts/freescale/imx8mp-evk-rpmsg.dts @@ -8,11 +8,6 @@ #include "imx8mp-evk.dts" / { - aliases { - i2c0 = &i2c1; - i2c1 = &i2c2; - i2c2 = &i2c_rpbus_3; - }; reserved-memory { #address-cells = <2>; @@ -45,70 +40,6 @@ rsc_table: rsc-table@550ff000 { no-map; }; - audio_reserved: audio@81000000 { - compatible = "shared-dma-pool"; - no-map; - reg = <0 0x81000000 0 0x10000000>; - }; - - micfil_reserved: mic_rpmsg@91000000 { - compatible = "shared-dma-pool"; - no-map; - reg = <0 0x91000000 0 0x100000>; - }; - }; - - sound-wm8960 { - status = "disabled"; - }; - - sound-micfil { - status = "disabled"; - }; - - rpmsg_audio: rpmsg_audio { - compatible = "fsl,imx8mp-rpmsg-audio"; - model = "wm8960-audio"; - fsl,rpmsg-channel-name = "rpmsg-audio-channel"; - fsl,enable-lpa; - fsl,rpmsg-out; - fsl,rpmsg-in; - assigned-clocks = <&clk IMX8MP_CLK_SAI3>; - assigned-clock-parents = <&clk IMX8MP_AUDIO_PLL1_OUT>; - assigned-clock-rates = <12288000>; - clocks = <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_SAI3_IPG>, - <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_SAI3_MCLK1>, - <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_SDMA3_ROOT>, - <&clk IMX8MP_AUDIO_PLL1_OUT>, - <&clk IMX8MP_AUDIO_PLL2_OUT>; - clock-names = "ipg", "mclk", "dma", "pll8k", "pll11k"; - audio-codec = <&codec>; - memory-region = <&audio_reserved>; - power-domains = <&audiomix_pd>; - audio-routing = - "LINPUT1", "MICB", - "LINPUT3", "MICB"; - status = "okay"; - }; - - rpmsg_micfil: rpmsg_micfil { - compatible = "fsl,imx8mp-rpmsg-audio"; - model = "micfil-audio"; - fsl,rpmsg-channel-name = "rpmsg-micfil-channel"; - fsl,enable-lpa; - fsl,rpmsg-in; - assigned-clocks = <&clk IMX8MP_CLK_PDM>; - assigned-clock-parents = <&clk IMX8MP_AUDIO_PLL1_OUT>; - assigned-clock-rates = <196608000>; - clocks = <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_PDM_IPG>, - <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_PDM_ROOT>, - <&audio_blk_ctrl IMX8MP_CLK_AUDIOMIX_SDMA3_ROOT>, - <&clk IMX8MP_AUDIO_PLL1_OUT>, - <&clk IMX8MP_AUDIO_PLL2_OUT>; - clock-names = "ipg", "mclk", "dma", "pll8k", "pll11k"; - memory-region = <&micfil_reserved>; - power-domains = <&audiomix_pd>; - status = "okay"; }; imx8mp-cm7 { @@ -144,72 +75,10 @@ &flexspi { status = "disabled"; }; -/delete-node/ &i2c3; - -&i2c_rpbus_3 { - compatible = "fsl,i2c-rpbus"; - #address-cells = <1>; - #size-cells = <0>; - status = "okay"; - - pca6416: gpio@20 { - compatible = "ti,tca6416"; - reg = <0x20>; - gpio-controller; - #gpio-cells = <2>; - }; - - ov5640_1: ov5640_mipi@3c { - compatible = "ovti,ov5640"; - reg = <0x3c>; - pinctrl-names = "default"; - pinctrl-0 = <&pinctrl_csi0_pwn>, <&pinctrl_csi0_rst>; - clocks = <&clk IMX8MP_CLK_IPP_DO_CLKO2>; - clock-names = "xclk"; - assigned-clocks = <&clk IMX8MP_CLK_IPP_DO_CLKO2>; - assigned-clock-parents = <&clk IMX8MP_CLK_24M>; - assigned-clock-rates = <24000000>; - csi_id = <0>; - powerdown-gpios = <&gpio4 1 GPIO_ACTIVE_HIGH>; - reset-gpios = <&gpio4 0 GPIO_ACTIVE_LOW>; - mclk = <24000000>; - mclk_source = <0>; - mipi_csi; - status = "disabled"; - - port { - ov5640_mipi_1_ep: endpoint { - remote-endpoint = <&mipi_csi1_ep>; - data-lanes = <1 2>; - clock-lanes = <0>; - }; - }; - }; - - codec: wm8960@1a { - compatible = "wlf,wm8960,lpa"; - reg = <0x1a>; - wlf,shared-lrclk; - SPKVDD1-supply = <&reg_audio_pwr>; - }; -}; - &pwm4{ status = "disabled"; }; -&sai3 { - status = "disabled"; -}; - -&micfil { - status = "disabled"; -}; - -&sdma3{ - status = "disabled"; -}; - &uart3 { status = "disabled"; };   Result We can play audio on wm8960 after we load M7 firmware.

This article describe i.M93 RGMII to PHY connection, delay adding tips. i.MX93 don't support delay in both FEC and QOS port in i.MX93 side. It also provide solution on i.MX93 how to connect MAC to MAC in HW & SW. Thanks! 

In some cases, due to the limited resources allocated by imx pins, gpio has to be used as mdio/mdc. This article is a simple guide on how to use MDIO on GPIOs. The demo code is for network fec interface. 1. Add CONFIG_MDIO_GPIO=y and rebuild kernel 2. Modify fec device tree to use MDIO ON GPIO FEC test result: root@imx93evk:~# ethtool eth0 Settings for eth0:         Supported ports: [ TP    MII ]         Supported link modes:   10baseT/Half 10baseT/Full                                 100baseT/Half 100baseT/Full                                 1000baseT/Full         Supported pause frame use: Symmetric         Supports auto-negotiation: Yes         Supported FEC modes: Not reported         Advertised link modes:  10baseT/Half 10baseT/Full                                 100baseT/Half 100baseT/Full                                 1000baseT/Full         Advertised pause frame use: Symmetric         Advertised auto-negotiation: Yes         Advertised FEC modes: Not reported         Link partner advertised link modes:  10baseT/Half 10baseT/Full                                              100baseT/Half 100baseT/Full                                              1000baseT/Full         Link partner advertised pause frame use: No         Link partner advertised auto-negotiation: Yes         Link partner advertised FEC modes: Not reported         Speed: 1000Mb/s         Duplex: Full         Auto-negotiation: on         master-slave cfg: preferred slave         master-slave status: slave         Port: Twisted Pair         PHYAD: 2         Transceiver: external         MDI-X: Unknown         Supports Wake-on: g         Wake-on: d         Link detected: yes root@imx93evk:~# ifconfig eth0: flags=-28605<UP,BROADCAST,RUNNING,MULTICAST,DYNAMIC>  mtu 1500         inet 10.192.246.129  netmask 255.255.255.0  broadcast 10.192.246.255         inet6 fe80::885a:aeff:fea3:7dcf  prefixlen 64  scopeid 0x20<link>         ether 8a:5a:ae:a3:7d:cf  txqueuelen 1000  (Ethernet)         RX packets 13  bytes 2294 (2.2 KiB)         RX errors 0  dropped 3  overruns 0  frame 0         TX packets 25  bytes 4691 (4.5 KiB)         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0   eth1: flags=-28669<UP,BROADCAST,MULTICAST,DYNAMIC>  mtu 1500         ether a2:5e:45:17:72:79  txqueuelen 1000   eQOS test result imx93evk login: root root@imx93evk:~# ifconfig eth0: flags=-28669<UP,BROADCAST,MULTICAST,DYNAMIC> mtu 1500 ether 00:04:9f:08:7f:d0 txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 eth1: flags=-28605<UP,BROADCAST,RUNNING,MULTICAST,DYNAMIC> mtu 1500 inet 10.192.246.112 netmask 255.255.255.0 broadcast 10.192.246.255 inet6 fe80::204:9fff:fe08:7fcf prefixlen 64 scopeid 0x20<link> ether 00:04:9f:08:7f:cf txqueuelen 1000 (Ethernet) RX packets 12 bytes 3020 (2.9 KiB) RX errors 0 dropped 3 overruns 0 frame 0 TX packets 31 bytes 5355 (5.2 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 104 root@imx93evk:~# ethtool eth1 Settings for eth1: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supported pause frame use: Symmetric Receive-only Supports auto-negotiation: Yes Supported FEC modes: Not reported Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised pause frame use: Symmetric Receive-only Advertised auto-negotiation: Yes Advertised FEC modes: Not reported Link partner advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Link partner advertised pause frame use: No Link partner advertised auto-negotiation: Yes Link partner advertised FEC modes: Not reported Speed: 1000Mb/s Duplex: Full Auto-negotiation: on master-slave cfg: preferred slave master-slave status: slave Port: Twisted Pair PHYAD: 1 Transceiver: external MDI-X: Unknown Supports Wake-on: ug Wake-on: d Current message level: 0x0000003f (63) drv probe l

Test Environment： i.MX8MP EVK L6.6.52(weston12)   Background Current RDP only supports TLS authentication, but does not support the NLA feature or PAM password authentication. Therefore, the connection security of RDP will be very low, and you can even login remotely without the correct username and password. This article implements the NLA feature and PAM password authentication base on weston rdp backend, which supports customized user and login.   1.Patches patch weston-imx with add_rdp_pam_nla_support.patch patch meta-imx with add_pam_support_and_weston_user.patch   2.Generate keys on Ubuntu rename key as server.crt and server.key sudo apt-get install winpr-utils winpr-makecert -rdp -path ~/ copy server.crt and server.key from Ubuntu to /etc/freerdp/keys/ on i.MX board 3. Enable start-on-startup=true in weston.ini   4.Install Remmina on Ubuntu.   5.Generate SAM file on board and Ubuntu: /etc/winpr/SAM(SAM is a file, not a directory) and copy hash into /etc/winpr/SAM The username weston and passwd has been set in add_pam_support_and_weston_user.patch. username: weston passwd: weston domain: domain   $ winpr-hash -u weston -d domain -p weston -v1 -f sam weston:domain::b2ca4ec6a1dbd13c49b6ab5e1b10d5bf::: $ vi /etc/winpr/SAM   6.Access with Remmina on Ubuntu. 7.Result      

Kindly note that application note “AN12812: Using Code-Signing Tool with Hardware Security Module" has been removed from nxp.com. The AN is obsolete, the CST User’s guide describes how to use CST with an HSM using PKCS#11 interface. You can download CST package with its documentation from https://www.nxp.com/webapp/sps/download/license.jsp?colCode=IMX_CST_TOOL_NEW  

Hello everyone, this post is intended to add support to one of the most popular NFC chips on the market (PN532).  On this example I will use the I.MX93 EVK as reference board and focused in I2C communication for the PN532 Chip.    Details:   I.MX93 EVK  PN532 Module (I2C, SPI, UART)  BSP Linux 6.6.36_2.1.0 (Yocto)      STEP 1 (IMAGE COMPILATION).    At first, we need to compile our image for our board (in my case I.MX93 EVK) to add the NFC layer (Details on Yocto User's Guide😞😞 $ mkdir yocto-bsp $cd yocto-bsp $ repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-scarthgap -m imx-6.6.36-2.1.0.xml $ repo sync $DISTRO=fsl-imx-wayland MACHINE=imx93evk source imx-setup-release.sh -b imx93evk-build   Then, add the support for NFC in our local.conf file:  $ nano conf/local.conf   We will add the below lines: CORE_IMAGE_EXTRA_INSTALL += "libnfc" CORE_IMAGE_EXTRA_INSTALL += "libnfc-dev"   Then, we can compile the image with:  $ bitbake imx-image-full   NOTE:  libnfc is a complete coverage of low-level PN53x chipset commands written in pure and plain C for portability and speed.  libnfc-dev are the development files and headers to use in our low-level applications.    By default, the NXP BSP support the NFC pn532 driver with a tool called nfctool, but this one is very limited compared with the libnfc.      STEP 2 (DEVICE TREE MODIFICATION).    We need to add the below lines to the Device tree:  &lpi2c5 { #address-cells = <1>; #size-cells = <0>; clock-frequency = <400000>; pinctrl-names = "default", "sleep"; pinctrl-0 = <&pinctrl_lpi2c5>; pinctrl-1 = <&pinctrl_lpi2c5>; status = "okay"; nfc@24 { compatible = "nxp,nxpnfc"; //we can set the "nxp,pn533" driver but it will just work for the nfctool mentioned before reg = <0x24>; clock-frequency = <400000>; interrupt-parent = <&gpio2>; interrupts = <18 IRQ_TYPE_EDGE_FALLING>; }; };    And to the iomux section(same in device tree):  pinctrl_lpi2c5: lpi2c5grp { fsl,pins = < MX93_PAD_GPIO_IO22__LPI2C5_SDA 0x40000b9e MX93_PAD_GPIO_IO23__LPI2C5_SCL 0x40000b9e MX93_PAD_GPIO_IO18__GPIO2_IO18 0x31e >; };     STEP 3 (Connection with PN532 MODULE).     For this example, we must connect the Module with the I.MX93 RP Header as follows:    I.MX93 SIDE  PN532 SIDE  GND  GND  VCC  VCC  GPIO_IO22  SDA  GPIO_IO23  SCL  GPIO_IO18  IRQ    STEP 4 (BOOT BOARD AND CREATE libnfc.conf FILE).    Once when we have booted our board and selected our modified Device Tree, we should see our i2c-4 under /dev of our Linux OS: root@imx93evk:~# ls /dev | grep i2c i2c-0 i2c-1 i2c-2 i2c-4   And see our specific device (0x24) with the i2cdetect tool:   root@imx93evk:~# i2cdetect -y 4 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- 24 -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- --     Now, we need to create a file called libnfc.conf under /etc/nfc/ (You can create that directory if does not exist).  This file must contain information about how the libnfc layer will communicate with the i2c device:    # Allow device auto-detection (default: true) # Note: if this auto-detection is disabled, user has to set manually a device # configuration using file or environment variable allow_autoscan = false # Allow intrusive auto-detection (default: false) # Warning: intrusive auto-detection can seriously disturb other devices # This option is not recommended, user should prefer to add manually his device. allow_intrusive_scan = true # Set log level (default: error) # Valid log levels are (in order of verbosity): 0 (none), 1 (error), 2 (info), 3 (debug) # Note: if you compiled with --enable-debug option, the default log level is "debug" log_level = 2 # Manually set default device (no default) # To set a default device, you must set both name and connstring for your device # Note: if autoscan is enabled, default device will be the first device available in device list. #device.name = "_PN532_SPI" #device.connstring = "pn532_spi:/dev/spidev0.0:500000" device.name = "_PN532_I2c" device.connstring = "pn532_i2c:/dev/i2c-4"   As you can see, the most important line to modify is the device.connstring, that is the charged of interaction and connection between the PN53x Module and the libnfc layer. In my case is pn532_i2c:/dev/i2c-4.    Now we can use the NFC module:  root@imx93evk:~# nfc-list nfc-list uses libnfc 1.8.0 NFC device: _PN532_I2c opened root@imx93evk:~#   And read UID of TAGs:  root@imx93evk:~# nfc-poll nfc-poll uses libnfc 1.8.0 NFC reader: _PN532_I2c opened NFC device will poll during 36000 ms (20 pollings of 300 ms for 6 modulations) ISO/IEC 14443A (106 kbps) target: ATQA (SENS_RES): 00 44 UID (NFCID1): 04 17 b5 d2 a2 11 90 SAK (SEL_RES): 00 Waiting for card removing...nfc_initiator_target_is_present: Target Released done. root@imx93evk:~#   Also, attached is a little application using the NFC headers installed with libnfc-dev. Tha application will do a poll with a 10 seconds time out. If Tag is not detected in 10 seconds, the app will close. If a tag is detected before the timeout, the app will print the UID of the NFC TAG:   OUTPUT of timeout: root@imx93evk:~# ./nfc-app NFC reader: _PN532_I2c opened Waiting for an NFC tag (timeout: 10 seconds)... No NFC tag detected within the timeout period. root@imx93evk:~#   OUTPUT when tag is detected: root@imx93evk:~# ./nfc-app NFC reader: _PN532_I2c opened Waiting for an NFC tag (timeout: 10 seconds)... Tag detected - UID: 04:16:BC:D2:A2:11:90 root@imx93evk:~#   To compile the app just copy the attached nfc-app.c file to the i.MX93 EVK and compile using this command: root@imx93evk:~# gcc nfc-app.c -o nfc-app -lnfc     I hope this thread can be helpful!   Best regards, Salas.  

This article demonstrates several simple gpio leds as system indicators, including kernel panic indicators.   HW: i.MX93 11x11 EVK SW: lf-6.6.3-1.0.0    

 

 

 

    Test envs: BOARD: i.MX 8MN EVK BSP: L6.6.36   The L6.6.y includes the feature about supporting starting Cortex-M33 from non-TCM address for i.MX93, but not for i.MX8M series.    LF-7815 remoteproc: imx_rproc: support starting Cortex-M33 from non-TCM address for i.MX93 https://github.com/nxp-imx/linux-imx/commit/680aa11c7bdaddf6bbffd74bc0a94ef67593b69b#diff-66a34e17e82d281936f559217adc3983b39abeb2e478967f3d5cef2eed5b67fcR693   For older BSP, customer can refer this full patch set https://patchew.org/linux/[email protected]/   If you want to test ELF in DDR on i.MX8M series and i.MX93 platform with L6.6.y, please use below patch set.  

some customers have issue with uboot resetting on new bsp because of lack of mac address and different design fom nxp evk board, this doc shows how to set the mac address in different way(fuse, dts file, header file), then check the different HW design between customized board with nxp board, according to the HW design to change the uboot 

Please notice the following patches are only tested in the environment that is listed below. For the environment with other software versions or hardware equipment, some other editing  may be required Environment: i.MX 8MP EVK MIPI DSI: MX8-DSI-OLED1 (RM67191) Software: LF5.15.71 U-boot: 1. Apply '0001-Modify-u-boot-to-show-logo-seamlessly.patch' to make sure display related models won't be power off, which will help to achieve seamless display. Kernel: 1. Apply '0001-Keep-NXP-logo-until-Weston-is-booted-8MP-MIPI.patch' to make sure MIPI-DSI related models won't be re-init in the booting progress.

Please notice the following patches are only tested in the environment that is listed below. For the environment with other software versions or hardware equipment, some other editing  may be required Environment: i.MX 93 EVK LVDS：LVDS BOE EV121WXM-N10-1850  Software: LF6.1.36 U-boot: 1. Apply '0001-Add-LVDS-driver-and-BOE-12.1-EV121WXM-N10-1850-LVDS-.patch' to enable EV121WXM-N10-1850  in U-boot stage. If other LVDS panel is used here, you will need porting your specific LVDS device in this step. 2. Apply '0002-Modify-u-boot-to-show-logo-seamlessly.patch' to make sure display related models won't be power off, which will help to achieve seamless display. Kernel: 1. Apply '0001-Keep-NXP-logo-until-Weston-is-booted-for-i.MX93-in-L.patch' to make sure LVDS related models won't be init in the booting progress.

Please notice the following patches are only tested in the environment that is listed below. For the environment with other software versions or hardware equipment, some other editing  may be required Environment: i.MX 8MP EVK LVDS：LVDS BOE EV121WXM-N10-1850  LVDS to MiniSAS panel：XMX-LVDS-MINISAS Software: LF5.15.71 U-boot: 1. Apply '0001-Enable-DY1212W-4856-in-U-boot-for-i.MX8MP.patch' to enable EV121WXM-N10-1850  in U-boot stage. If other LVDS panel is used here, you will need porting your specific LVDS device in this step. 2. Apply '0002-Modify-u-boot-to-show-logo-seamlessly-for-i.MX8MP.patch' to make sure display related models won't be power off, which will help to achieve seamless display. 3. In the original U-boot driver, PWM isn't enable. Therefore, apply '0003-Enable-PWM-and-BACKLIGHT-in-U-boot-and-modify-to-sho.patch' to enable PWM. Kernel: 1. Apply '0001-Enable-DY1212W-4856-in-Kernl-for-i.MX8MP.patch' to enable EV121WXM-N10-1850  in Kernel. If other LVDS panel is used here, you will need porting your specific LVDS device in this step. 2. Apply '0002-Modify-Kernel-to-show-logo-seamlessly-for-i.MX8MP.patch' to make sure LVDS related models won't be init in the booting progress. 3. Apply '0003-Enable-PWM-and-BACKLIGHT-in-Kernel-and-modify-to-sho.patch' to make sure we could edit backlight of panel in Kernel.