Xenomai is real-time framework, which can run seamlessly side-by-side Linux as a co-kernel system, or natively over mainline Linux kernels (with or without PREEMPT-RT patch). The dual kernel nicknamed Cobalt, is a significant rework of the Xenomai 2.x system. Cobalt implements the RTDM specification for interfacing with real-time device drivers. The native linux version, an enhanced implementation of the experimental Xenomai/SOLO work, is called Mercury. In this environment, only a standalone implementation of the RTDM specification in a kernel module is required, for interfacing the RTDM-compliant device drivers with the native kernel. You can get more detailed information from Home · Wiki · xenomai / xenomai · GitLab       I have ported xenomai 3.1 to i.MX Yocto 4.19.35-1.1.0, and currently support ARM64 and test on i.MX8MQ EVK board. I did over night test( 5 real-time threads + GPU SDK test case) and stress test by tool stress-ng on i.MX8MQ EVK board. It looks lile pretty good. Current version (20200730) also support i.MX8MM EVK.     You need git clone https://gitee.com/zxd2021-imx/xenomai-arm64.git, and git checkout xenomai-4.19.35-1.1.0-20200818 (which inlcudes all patches and bb file) and add the following variable in conf/local.conf before build xenomai by command bitbake xenomai.  XENOMAI_KERNEL_MODE = "cobalt"  PREFERRED_VERSION_linux-imx = "4.19-${XENOMAI_KERNEL_MODE}" IMAGE_INSTALL_append += " xenomai" or XENOMAI_KERNEL_MODE = "mercury" PREFERRED_VERSION_linux-imx = "4.19-${XENOMAI_KERNEL_MODE}" IMAGE_INSTALL_append += " xenomai" If XENOMAI_KERNEL_MODE = "cobalt", you can build dual kernel version. And If XENOMAI_KERNEL_MODE = "mercury", it is single kernel with PREEMPT-RT patch. The following is test result by the command (/usr/xenomai/demo/cyclictest -p 99 -t 5 -m -n -i 1000  -l 100000😞 //Over normal Linux kernel without GPU SDK test case T: 0 ( 4220) P:99 I:1000 C: 100000 Min: 7 Act: 10 Avg: 9 Max: 23 T: 1 ( 4221) P:99 I:1500 C: 66672 Min: 7 Act: 10 Avg: 10 Max: 20 T: 2 ( 4222) P:99 I:2000 C: 50001 Min: 7 Act: 12 Avg: 10 Max: 81 T: 3 ( 4223) P:99 I:2500 C: 39998 Min: 7 Act: 11 Avg: 10 Max: 29 T: 4 ( 4224) P:99 I:3000 C: 33330 Min: 7 Act: 13 Avg: 10 Max: 26 //Over normal Linux kernel with GPU SDK test case T: 0 ( 4177) P:99 I:1000 C: 100000 Min: 7 Act: 10 Avg: 11 Max: 51 T: 1 ( 4178) P:99 I:1500 C: 66673 Min: 7 Act: 12 Avg: 10 Max: 35 T: 2 ( 4179) P:99 I:2000 C: 50002 Min: 7 Act: 12 Avg: 11 Max: 38 T: 3 ( 4180) P:99 I:2500 C: 39999 Min: 7 Act: 12 Avg: 11 Max: 42 T: 4 ( 4181) P:99 I:3000 C: 33330 Min: 7 Act: 12 Avg: 11 Max: 36   //Cobalt with stress-ng --cpu 4 --io 2 --vm 1 --vm-bytes 512M --timeout 600s --metrics-brief T: 0 ( 4259) P:50 I:1000 C:3508590 Min:      0 Act:    0 Avg:    0 Max:      42 T: 1 ( 4260) P:50 I:1500 C:2338831 Min:      0 Act:    1 Avg:    0 Max:      36 T: 2 ( 4261) P:50 I:2000 C:1754123 Min:      0 Act:    1 Avg:    1 Max:      42 T: 3 ( 4262) P:50 I:2500 C:1403298 Min:      0 Act:    1 Avg:    1 Max:      45 T: 4 ( 4263) P:50 I:3000 C:1169415 Min:      0 Act:    1 Avg:    1 Max:      22   //Cobalt without GPU SDK test case T: 0 ( 4230) P:50 I:1000 C: 100000 Min: 0 Act: 0 Avg: 0 Max: 4 T: 1 ( 4231) P:50 I:1500 C:   66676 Min: 0 Act: 1 Avg: 0 Max: 4 T: 2 ( 4232) P:50 I:2000 C:   50007 Min: 0 Act: 1 Avg: 0 Max: 8 T: 3 ( 4233) P:50 I:2500 C:   40005 Min: 0 Act: 1 Avg: 0 Max: 3 T: 4 ( 4234) P:50 I:3000 C:   33338 Min: 0 Act: 1 Avg: 0 Max: 5 //Cobalt with GPU SDK test case T: 0 ( 4184) P:99 I:1000 C:37722968 Min: 0 Act: 1 Avg: 0 Max: 24 T: 1 ( 4185) P:99 I:1500 C:25148645 Min: 0 Act: 1 Avg: 0 Max: 33 T: 2 ( 4186) P:99 I:2000 C:18861483 Min: 0 Act: 1 Avg: 0 Max: 22 T: 3 ( 4187) P:99 I:2500 C:15089187 Min: 0 Act: 1 Avg: 0 Max: 23 T: 4 ( 4188) P:99 I:3000 C:12574322 Min: 0 Act: 1 Avg: 0 Max: 29 //Mercury without GPU SDK test case T: 0 ( 4287) P:99 I:1000 C:1000000 Min: 6 Act: 7 Avg: 7 Max: 20 T: 1 ( 4288) P:99 I:1500 C:  666667 Min: 6 Act: 9 Avg: 7 Max: 17 T: 2 ( 4289) P:99 I:2000 C:  499994 Min: 6 Act: 8 Avg: 7 Max: 24 T: 3 ( 4290) P:99 I:2500 C:  399991 Min: 6 Act: 9 Avg: 7 Max: 19 T: 4 ( 4291) P:99 I:3000 C:  333322 Min: 6 Act: 8 Avg: 7 Max: 21 //Mercury with GPU SDK test case T: 0 ( 4222) P:99 I:1000 C:1236790 Min: 6 Act: 7 Avg: 7 Max: 55 T: 1 ( 4223) P:99 I:1500 C:  824518 Min: 6 Act: 7 Avg: 7 Max: 44 T: 2 ( 4224) P:99 I:2000 C:  618382 Min: 6 Act: 8 Avg: 8 Max: 88 T: 3 ( 4225) P:99 I:2500 C:  494701 Min: 6 Act: 7 Avg: 8 Max: 49 T: 4 ( 4226) P:99 I:3000 C:  412247 Min: 6 Act: 7 Avg: 8 Max: 53 //////////////////////////////////////// Update for Yocto L5.4.47 2.2.0  /////////////////////////////////////////////////////////// New release for Yocto release L5.4.47 2.2.0 and it supports i.MX8M series (8MQ,8MM,8MN and 8MP). You need to git clone https://gitee.com/zxd2021-imx/xenomai-arm64.git,  and git checkout xenomai-5.4.47-2.2.0. You need to add the following variable in conf/local.conf before build xenomai by command bitbake imx-image-multimedia.  XENOMAI_KERNEL_MODE = "cobalt"  PREFERRED_VERSION_linux-imx = "5-${XENOMAI_KERNEL_MODE}" IMAGE_INSTALL_append += " xenomai" or XENOMAI_KERNEL_MODE = "mercury" PREFERRED_VERSION_linux-imx = "5-${XENOMAI_KERNEL_MODE}" IMAGE_INSTALL_append += " xenomai" //////////////////////////////////////// Update for Yocto L5.4.70 2.3.0  /////////////////////////////////////////////////////////// New release  for Yocto release L5.4.70 2.3.0 and it supports i.MX8M series (8MQ,8MM,8MN and 8MP) and i.MX8QM/QXP. You need to git clone https://gitee.com/zxd2021-imx/xenomai-arm64.git and git checkout xenomai-5.4.70-2.3.0. Updating: 1, Support i.MX8QM and i.MX8QXP 2, Fix altency's the issue which uses legacy API to get time   //////////////////////////////////////// update for Yocto L5.4.70 2.3.2  /////////////////////////////////////////////////////////// New release for Yocto release L5.4.70 2.3.2. You need to git clone https://gitee.com/zxd2021-imx/xenomai-arm64.git, and git checkout xenomai-5.4.70-2.3.2. Updating: 1, Enable Xenomai RTDM driver in Linux Kernel 2, Currently CAN, UART, GPIO,  SPI and Ethernet (in debug for RTNet)  are added in Xenomai. 3, Add KERNEL_DEVICETREE += " freescale/imx8mp-rt-evk.dtb " in sources/meta-imx/meta-bsp/conf/machine/imx8mpevk.conf to enable relative device in Xenomai domain, for example rt-imx8mp-flexcan.   //////////////////////////////////////// Update for Yocto L5.4.70 2.3.4  /////////////////////////////////////////////////////////// New release for Yocto release L5.4.70 2.3.4. You need to git clone  https://gitee.com/zxd2021-imx/xenomai-arm64.git and git checkout xenomai-5.4.70-2.3.4. Updating: 1, Enable RTNet FEC driver 2, Currently CAN, UART, GPIO,  SPI and Ethernet ( FEC Controller)  are added in Xenomai. 3, Add KERNEL_DEVICETREE += " freescale/imx8mp-rt-evk.dtb " in sources/meta-imx/meta-bsp/conf/machine/imx8mpevk.conf and KERNEL_DEVICETREE += " freescale/imx8mm-rt-ddr4-evk.dtb " in sources/meta-imx/meta-bsp/conf/machine/imx8mmddr4evk.conf to enable rt_fec device in Xenomai domain. Verifying the network connection by RTnet Ping Between i.MX8M Mini EVK and i.MX8M Plus EVK a, Setup test environment 1, Connect ENET1 of  i.MX8M Plus EVK (used as a master) and  ENET of i.MX8M Mini EVK (used as a slave) of  to a switch or hub 2, Modify /usr/xenomai/etc/rtnet.conf in i.MX8M Plus EVK board as the following: @@ -16,7 +16,7 @@ MODULE_EXT=".ko" # RT-NIC driver -RT_DRIVER="rt_eepro100" +RT_DRIVER="rt_fec" RT_DRIVER_OPTIONS="" # PCI addresses of RT-NICs to claim (format: 0000:00:00.0) @@ -30,8 +30,8 @@ REBIND_RT_NICS="" # The TDMA_CONFIG file overrides these parameters for masters and backup # masters. Leave blank if you do not use IP addresses or if this station is # intended to retrieve its IP from the master based on its MAC address. -IPADDR="10.0.0.1" -NETMASK="" +IPADDR="192.168.100.101" +NETMASK="255.255.255.0" # Start realtime loopback device ("yes" or "no") RT_LOOPBACK="yes" @@ -65,7 +65,7 @@ TDMA_MODE="master" # Master parameters # Simple setup: List of TDMA slaves -TDMA_SLAVES="10.0.0.2 10.0.0.3 10.0.0.4" +TDMA_SLAVES="192.168.100.102" # Simple setup: Cycle time in microsecond TDMA_CYCLE="5000" 3, Modify /usr/xenomai/etc/rtnet.conf in i.MX8M Mini EVK board as the following: @@ -16,7 +16,7 @@ MODULE_EXT=".ko" # RT-NIC driver -RT_DRIVER="rt_eepro100" +RT_DRIVER="rt_fec" RT_DRIVER_OPTIONS="" # PCI addresses of RT-NICs to claim (format: 0000:00:00.0) @@ -30,8 +30,8 @@ REBIND_RT_NICS="" # The TDMA_CONFIG file overrides these parameters for masters and backup # masters. Leave blank if you do not use IP addresses or if this station is # intended to retrieve its IP from the master based on its MAC address. -IPADDR="10.0.0.1" -NETMASK="" +IPADDR="192.168.100.102" +NETMASK="255.255.255.0" # Start realtime loopback device ("yes" or "no") RT_LOOPBACK="yes" @@ -59,13 +59,13 @@ STAGE_2_CMDS="" # TDMA mode of the station ("master" or "slave") # Start backup masters in slave mode, it will then be switched to master # mode automatically during startup. -TDMA_MODE="master" +TDMA_MODE="slave" # Master parameters # Simple setup: List of TDMA slaves -TDMA_SLAVES="10.0.0.2 10.0.0.3 10.0.0.4" +TDMA_SLAVES="192.168.100.102" # Simple setup: Cycle time in microsecond TDMA_CYCLE="5000" 4, rename imx8mm-rt-ddr4-evk.dtb to imx8mm-ddr4-evk.dtb in /run/media/mmcblk1p1,  rename imx8mp-rt-evk.dtb to imx8mp-evk.dtb in /run/media/mmcblk1p1, and reboot board. 5, Run the below command on i.MX8M Mini EVK board. cd /usr/xenomai/sbin/ ./rtnet start & 5, Run the below command on i.MX8M Plus EVK board. cd /usr/xenomai/sbin/ ./rtnet start & When you see the log (rt_fec_main 30be0000.ethernet (unnamed net_device) (uninitialized): Link is Up - 100Mbps/Full - flow control rx/tx) and you can run command "./rtroute" to check route table if the slave IP (192.168.100.102) is in route.. b, Verify the network connection using the command below: ./rtping -s 1024 192.168.100.102 //////////////////////////////////////// Update for Yocto L5.10.52 2.1.0  /////////////////////////////////////////////////////////// New release for Yocto release L5.10.52 2.1.0. You need to git clone https://gitee.com/zxd2021-imx/xenomai-arm64.git and git checkout xenomai-5.10.52-2.1.0. Updating: 1, Upgrade Xenomai to v3.2 2, Enable Dovetail instead of ipipe. Copy xenomai-arm64 to <Yocto folder>/sources/meta-imx/meta-bsp/recipes-kernel, and add the following variable in conf/local.conf before build Image with xenomai enable by command bitbake imx-image-multimedia. XENOMAI_KERNEL_MODE = "cobalt" IMAGE_INSTALL_append += " xenomai" or XENOMAI_KERNEL_MODE = "mercury" IMAGE_INSTALL_append += " xenomai" Notice: If XENOMAI_KERNEL_MODE = "cobalt", you can build dual kernel version. And If XENOMAI_KERNEL_MODE = "mercury", it is single kernel with PREEMPT-RT patch.  Latency testing of Xenomai3.2+Dovetail with isolating CPU 2,3 ( Xenomai 3.2 on 8MM DDR4 EVK with GPU test case (GLES2/S08_EnvironmentMappingRefraction_Wayland) + iperf3 + 2 ping 65000 size + stress-ng --cpu 2 --io 2 --vm 1 --vm-bytes 256M --metrics-brief )😞 The following is test result by the command (/usr/xenomai/demo/cyclictest -a 2,3 -p 50 -t 5 -m -n -i 1000) root@imx8mmddr4evk:~# /usr/xenomai/demo/cyclictest -a 2,3 -p 50 -t 5 -m -n -i 1000 # /dev/cpu_dma_latency set to 0us policy: fifo: loadavg: 5.96 6.04 6.03 7/155 1349 T: 0 ( 615) P:50 I:1000 C:63448632 Min: 0 Act: 0 Avg: 0 Max: 55 T: 1 ( 616) P:50 I:1500 C:42299087 Min: 0 Act: 0 Avg: 1 Max: 43 T: 2 ( 617) P:50 I:2000 C:31724315 Min: 0 Act: 0 Avg: 1 Max: 51 T: 3 ( 618) P:50 I:2500 C:25379452 Min: 0 Act: 0 Avg: 1 Max: 53 T: 4 ( 619) P:50 I:3000 C:21149543 Min: 0 Act: 0 Avg: 1 Max: 47 //////////////////////////////////////// Update for Yocto L5.10.72 2.2.2  /////////////////////////////////////////////////////////// New release for Yocto release L5.10.72 2.2.2. You need to git clone https://gitee.com/zxd2021-imx/xenomai-arm64.git and git checkout xenomai-5.10.72-2.2.2. Updating: 1, Upgrade Xenomai to v3.2.1 Copy xenomai-arm64 to <Yocto folder>/sources/meta-imx/meta-bsp/recipes-kernel, and add the following variable in conf/local.conf before build Image with xenomai enable by command bitbake imx-image-multimedia. XENOMAI_KERNEL_MODE = "cobalt" IMAGE_INSTALL_append += " xenomai" or XENOMAI_KERNEL_MODE = "mercury" IMAGE_INSTALL_append += " xenomai" //////////////////////////////////////// Update for Yocto L5.15.71 2.2.0  /////////////////////////////////////////////////////////// New release for Yocto release L5.15.71 2.2.0. You need to git clone https://gitee.com/zxd2021-imx/xenomai-arm64.git and git checkout xenomai-5.15.71-2.2.0. Updating: 1, Upgrade Xenomai to v3.2.2 Copy xenomai-arm64 to <Yocto folder>/sources/meta-imx/meta-bsp/recipes-kernel, and add the following variable in conf/local.conf before build Image with xenomai enable by command bitbake imx-image-multimedia. XENOMAI_KERNEL_MODE = "cobalt" IMAGE_INSTALL:append += " xenomai" or XENOMAI_KERNEL_MODE = "mercury" IMAGE_INSTALL:append += " xenomai"   //////////////////////////////////////// Update for Yocto L6.1.55 2.2.0  /////////////////////////////////////////////////////////// New release for Yocto release L6.1.55 2.2.0. You need to git clone https://gitee.com/zxd2021-imx/xenomai-arm64.git recipes-rtlinux-xenomai -b Linux-6.1.x Updating: 1, Upgrade Xenomai to v3.2.4 and support i.MX93 2, Enable EVL (aka Xenomai 4) for i.MX93 and legacy i.MX(6/7D/8X/8M) Copy recipes-rtlinux-xenomai to <Yocto folder>/sources/meta-imx/meta-bsp/, and add the following variable in conf/local.conf before build Image with xenomai enable by command bitbake imx-image-multimedia. XENOMAI_KERNEL_MODE = "cobalt" IMAGE_INSTALL:append += " xenomai" or XENOMAI_KERNEL_MODE = "mercury" IMAGE_INSTALL:append += " xenomai" or XENOMAI_KERNEL_MODE = "evl" IMAGE_INSTALL:append += " libevl"  

Why SWPDM?   In order to process human voice, it is required to have the best audio resolution in the incoming data captured by the microphones. This mean, having a resolution of 16bits is not enough to capture all the information to properly process the voice. Voice processing requires a peripheral capable of capture data on a 32bits resolution within the range of the most common sample rates (16kHz, 44.1kHz, 48Khz, etc.). On the i.MX8M family there is a peripheral which fulfill those requirements and is called MICFIL. MICFIL is a peripheral which convert PDM (Pulse Density Modulation) data to PCM (Pulse-Code Modulation) data. The PDM format encode the analog signal in just one bit. Where 1 means the signal is increasing in amplitude while 0 means the opposite. In the other hand, the PCM format encode the data in 8, 16, or 32 bits. The advantage of PDM is that the creation of microphones is cheaper than having PCM microphones but then you will need a software or hardware which do the conversion for PDM to PCM since PDM cannot be processed. This is the reason of the MICFIL peripheral. However, not all the MICFIL's on the difference SOMs are the same. While the i.MX8MPLUS has a resolution of 32bits its smaller brothers do not. i.MX8MMINI and i.MX8MNANO have a MICFIL which only allows a resolution up to 16bits. For most of the cases it will be enough but not for voice processing. Nevertheless, not everything is lost; As mentioned previously, the PDM to PCM conversation can be done by hardware or by software. NXP also have the algorithm in software to do the conversation. Therefore, if a Mini or Nano is being used for voice processing it is fully recommended to use the ALSA SWPDM Plugin and avoid MICFIL peripheral.   Using the Plugin   In order to use the plugin, it is required to change the DTB to  imx8mm-evk-8mic-swpdm.dtb , when using the i.MX8MM or  imx8mn-evk-8mic-swpdm.dtb , when using the i.MX8MN. In order to do so follow the next steps: Please notice below example if for Mini. For Nano will be the same just changing the DTB name to imx8mn-evk-8mic-swpdm.dtb. # Stop at U-boot u-boot=> edit fdtfile edit: imx8mm-evk-8mic-swpmd.dtb u-boot=> saveenv u-boot=> boot   The change in the DTB is required to disable MICFIL so Linux can receive the raw data and sent it to the plugin. However, the plugin is not enabled by default, users need to explicit add the plugin to their ALSA pipeline. The way of doing so is by adding the following device to  /etc/asound.conf : pcm.cic { type cicFilter slave "hw:imxswpdmaudio,0" delay 100000 gain 0 OSR 48 }   Where: pcm.cic : Is an arbitrary name which allow ALSA to find the requested devices when setting the  -D  flag with  arecord  or  aplay . type cicFilter : This is the plugin type which is named with the algorithm name. slave: Name of the physical or virtual device which will be controlled by the cicFilter plugin. The recommendation is to always have the actual hardware connected to this plugin. delay : Amount of time in microsecond which the plugin won't write to the buffer, but it still does the conversion. The value could be between 100us to 1'000,000us. By removing the property from the structure, the delay will be set to 0. gain : A value between 0 and 100. OSR : Is related to the quality of the signal by increasing the PDM sample rate. With a higher valuer a best quality on the audio can be achieved. However, keep in mind than having a higher value will also require more memory to store all the new data due to the oversampling. The valid values for the OSR are: 48, 64, 96, 128, and 192. With all being said, the only thing left is to test the plugin by running the following command: $ arecord -D cic -c4 -r16000 -f s32_le --period-size=96 -d5 -v test.wav   Integration With AFE   The next and final step is integrating the plugin with AFE and VoiceSeeker. The integration of SWPDM requires to apply a patch to the SWPDM repository. The patch changes the amount of period sizes allowed on the plugin. By default, the plugin only allows certain values which are:  48 Samples = 3ch x 4bytes format x 16samples = 192 bytes. 48 Samples = 2ch x 4bytes format x 48samples = 384 bytes. 48 Samples = 4ch x 4bytes format x 48samples = 768 bytes. 96 Samples = 4ch x 4bytes format x 96samples = 1,536 bytes. Although, AFE and VoiceSeeker are extremely configurable, 48 or 96 samples for the algorithm is too small. Meaning that the SWPDM should support a bigger period size, not all the way around. By applying the attached file, the plugin can have a period size from 64 bytes (1ch and 16 samples) up to 16,384 bytes (4ch and 1024 samples). However, the number of samples can vary depending on the OSR value and the number of channels. Once the patch has been applied in must be installed on: /usr/lib/alsa-lib (if the repository is being built on a standalone environment). AFE opens a device called mic  for capture the microphones' input. This device can have anything below it. By default, have the following definition on /etc/asound.conf  (after following the steps described on the TODO.md file). # mic represents the physical source (capture) pcm.mic { type plug slave.pcm "hw:micfilaudio,0" }   The devices opens the MICFIL driver, but on this case MICFIL is disable, which means the definition of the device must change. From above cic  device the definition can be copy and paste and then tweak one parameter. The delay must be set to 0 by removing the property or setting it explicitly on the structure. If this step if forgotten this might cause some underrun issues. The device definition will be: pcm.mic { type cicFilter slave "hw:imxswpdmaudio,0" delay 0 gain 0 OSR 48 }   The last thing to do will be running AFE with VoiceSeeker as usual. $ /unit_tests/nxp-afe/voice_ui_app & $ /unit_tests/nxp-afe/afe libvoiceseekerlight &   Considerations and Restrictions With all that said, there are few things left to mention, which are the considerations and restrictions on the plugin itself. These are good things to know before adding the plugin into any application. The plugin is supported from the Linux BSP 5.15.32. Currently the plugin only supports up to 4 channels. Plugin only outputs a S32_LE format (if required another format please use MICFIL). By applying above patch, the period size must be a multiple of 16, due to a limitation on the algorithm itself, rather than the plugin. The driver only allows to have one microphone per data-line while MICFIL allows to have two microphones per data-line. The SWPDM Plugin is based on the External Plugin: I/O Plugin. This means it also have the restriction of this ALSA plugin, being the following restriction the most important one: "The I/O-type plugin is a PCM plugin to work as the input or output terminal point, i.e. as a user-space PCM driver". In other words, there can't be any device/plugin on top of it, not even a "plug" type. 

Background   Wake-on-LAN ( WoL) is an Ethernet computer networking standard that allows a computer to be turned on or awakened from sleep mode by a network message. The message is usually sent to the target computer by a program executed on a device connected to the same local area network. Ethernet connections, including home and work networks, wireless data networks, and the Internet itself, are based on frames sent between computers. WoL is implemented using a specially designed frame called a magic packet, which is sent to all computers in a network, among them the computer to be awakened. The magic packet contains the MAC address of the destination computer. This is an identifying number, built into each network interface controller (NIC)/Ethernet Controller, that enables the NIC/EnetController to be uniquely recognized and addressed on a network What is a WOL Magic packet? The magic packet is a frame that is most often sent as a broadcast and that contains anywhere within its payload 6 bytes of all 255 (FF FF FF FF FF FF in hexadecimal), followed by sixteen repetitions of the target computer's 48-bit MAC address, for a total of 102 bytes. it is typically sent as a UDP datagram to port 0 (reserved port number), 7 (Echo Protocol) or 9 (Discard Protocol) or directly over Ethernet using EtherType 0x0842   Configure iMX93EVK to wake up on an Ethernet Wake On LAN Magic Packet   Pre-requisite:- Install 'Wake on  LAN' utility on windows from the Microsoft Store. This utility uses Port 7 to send magic packet as a broadcast to the devices on the network.   Step-1 Make the dts change to enable wake-up functionality on eth1   In the following dts:- arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts   You would see the node entry for the corresponding ethernet, eth1 as eqos. Add fsl,magic-packet; to the node     After building the changes, boot with the imx93evk image.   Step-2 Enable wake on LAN By default in linux user-space the wake-on-lan is disabled, to enable the wake-on-lan run:  ethtool -s eth1 wol g     Now you are all set to wake up imx93evk via Ethernet WOL packet. Put the iMX93 to deep sleep via 'echo mem > /sys/power/state'   Step-3 Send WOL magic packet via Wake On LAN windows utility to wake up iMX93EVK   Make sure the devices are connected to the same local network like imx93evk and laptop connected to the same L2 switch. Add your imx93evk device to Wake on LAN software, you have to give iMX93EVK's MAC address of the ethernet that the RJ45 cable is connected to[you can get this from 'ifconfig -a' output].     After adding the device, it will look something like below:-     Right-click on the 'imx' device which is registered on Wake on LAN UI and click on 'Send WOL(magic packet)'. The moment you do that the WOL packet is sent to your iMX from your Laptop/PC on the same network and the iMX is woken up from deep sleep.     Hope you found it helpful. Please drop in any questions/comments just in case. 

Sometimes we need to use an SPI bus to communicate with sensors or another device. Unfortunately, by default on iMX8MN-EVK, we have the ECSPI2 disabled on our BSP.   We can use that peripheral on Linux enabling it in the device tree.   To enable the ECSPI2 on the device tree we have to add the next on imx8mn-evk.dtsi:     status = "okay"; }; +&ecspi2 { + #address-cells = <1>; + #size-cells = <0>; + fsl,spi-num-chipselects = <1>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_ecspi2 &pinctrl_ecspi2_cs>; + cs-gpios = <&gpio5 13 GPIO_ACTIVE_LOW>; + status = "okay"; + + spidev0: spi@0 { + reg = <0>; + compatible = "rohm,dh2228fv"; + spi-max-frequency = <500000>; + }; +}; + &fec1 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_fec1>;   On iomux node:   + pinctrl_ecspi2: ecspi2grp { + fsl,pins = < + MX8MN_IOMUXC_ECSPI2_SCLK_ECSPI2_SCLK 0x82 + MX8MN_IOMUXC_ECSPI2_MOSI_ECSPI2_MOSI 0x82 + MX8MN_IOMUXC_ECSPI2_MISO_ECSPI2_MISO 0x82 + >; + }; + + pinctrl_ecspi2_cs: ecspi2cs { + fsl,pins = < + MX8MN_IOMUXC_ECSPI2_SS0_GPIO5_IO13 0x40000 + >; + }; + pinctrl_ir_recv: ir-recv { fsl,pins = < MX8MN_IOMUXC_GPIO1_IO13_GPIO1_IO13 0x4f    after modifying and compiling the device tree you can see the device active like this:     Connection:   Test: spidev_test -D /dev/spidev1.0 -v       You can use the devsheell of yocto to make the changes:   https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/How-to-use-Devshell-to-compile-device-tree-files/ta-p/1727428

  For some applications, we need to reduce the CPU Frequency, but if you are not familiar with our BSP or our devices probably you need some help to do some configurations.   In this post, I will share the configuration to set up lower frequencies (100MHz, 200MHz, 400Mhz, 600MHz, 800MHz, and 1000MHz) on iMX8MP, iMX8MN, and iMX8MM.   Note: Works on Kernel 6.1.xx (not tested on oldest BSP)   1- We have to modify the PLL driver to set the proper parameters to lower frequencies. The file to modify is "clk-pll14xx.c" adding the following lines:   https://github.com/nxp-imx/linux-imx/blob/770c5fe2c1d1529fae21b7043911cd50c6cf087e/drivers/clk/imx/clk-pll14xx.c#L57   static const struct imx_pll14xx_rate_table imx_pll1416x_tbl[] = { PLL_1416X_RATE(1800000000U, 225, 3, 0), PLL_1416X_RATE(1600000000U, 200, 3, 0), PLL_1416X_RATE(1500000000U, 375, 3, 1), PLL_1416X_RATE(1400000000U, 350, 3, 1), PLL_1416X_RATE(1200000000U, 300, 3, 1), PLL_1416X_RATE(1000000000U, 250, 3, 1), PLL_1416X_RATE(800000000U, 200, 3, 1), PLL_1416X_RATE(750000000U, 250, 2, 2), PLL_1416X_RATE(700000000U, 350, 3, 2), PLL_1416X_RATE(600000000U, 300, 3, 2), + PLL_1416X_RATE(400000000U, 200, 3, 2), + PLL_1416X_RATE(200000000U, 200, 3, 3), + PLL_1416X_RATE(100000000U, 200, 3, 4), };   2- Once the pll driver has been modified, only we have to add the values on the opp-table according to the device that you will use.   2.1- For iMX 8MP:   https://github.com/nxp-imx/linux-imx/blob/lf-6.1.y/arch/arm64/boot/dts/freescale/imx8mp.dtsi         a53_opp_table: opp-table { compatible = "operating-points-v2"; opp-shared; + opp-100000000 { + opp-hz = /bits/ 64 <100000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0x8a0>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-200000000 { + opp-hz = /bits/ 64 <200000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0x8a0>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-400000000 { + opp-hz = /bits/ 64 <400000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0x8a0>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-600000000 { + opp-hz = /bits/ 64 <600000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0x8a0>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-800000000 { + opp-hz = /bits/ 64 <800000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0x8a0>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-1000000000 { + opp-hz = /bits/ 64 <1000000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0x8a0>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; opp-1200000000 { opp-hz = /bits/ 64 <1200000000>;   2.2 For iMX8MM:   https://github.com/nxp-imx/linux-imx/blob/lf-6.1.y/arch/arm64/boot/dts/freescale/imx8mm.dtsi     a53_opp_table: opp-table { compatible = "operating-points-v2"; opp-shared; + opp-100000000 { + opp-hz = /bits/ 64 <100000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xe>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-200000000 { + opp-hz = /bits/ 64 <200000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xe>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-400000000 { + opp-hz = /bits/ 64 <400000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xe>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-600000000 { + opp-hz = /bits/ 64 <600000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xe>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-800000000 { + opp-hz = /bits/ 64 <800000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xe>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-1000000000 { + opp-hz = /bits/ 64 <1000000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xe>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; opp-1200000000 { opp-hz = /bits/ 64 <1200000000>;   2.3- For iMX8MN:   https://github.com/nxp-imx/linux-imx/blob/lf-6.1.y/arch/arm64/boot/dts/freescale/imx8mn.dtsi   compatible = "operating-points-v2"; opp-shared; + opp-100000000 { + opp-hz = /bits/ 64 <100000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xb00>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + + opp-200000000 { + opp-hz = /bits/ 64 <200000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xb00>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + + opp-400000000 { + opp-hz = /bits/ 64 <400000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xb00>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + + opp-600000000 { + opp-hz = /bits/ 64 <600000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xb00>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + + opp-800000000 { + opp-hz = /bits/ 64 <800000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xb00>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + + opp-1000000000 { + opp-hz = /bits/ 64 <1000000000>; + opp-microvolt = <850000>; + opp-supported-hw = <0xb00>, <0x7>; + clock-latency-ns = <150000>; + opp-suspend; + }; + opp-1200000000 { opp-hz = /bits/ 64 <1200000000>; opp-microvolt = <850000>;   After that, you should note the changes under Linux.   These commands return information about the system and the current settings.   • The kernel is pre-configured to support only certain frequencies. The list of frequencies currently supported can be obtained from: cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies   • To get the available scaling governors: cat /sys/devices/system/cpu/*/cpufreq/scaling_available_governors   • To check the current CPU frequency: cat /sys/devices/system/cpu/*/cpufreq/cpuinfo_cur_freq   The frequency is displayed depending on the governor set.   • To check the maximum frequency: cat /sys/devices/system/cpu/*/cpufreq/cpuinfo_max_freq   • To check the minimum frequency: cat /sys/devices/system/cpu/*/cpufreq/cpuinfo_min_freq   These commands set a constant CPU frequency:   • Use the maximum frequency: echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor   • Use the current frequency to be the constant frequency: echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor   • The following two commands set the scaling governor to a specified frequency, if that frequency is supported.   If the frequency is not supported, the closest supported frequency is used:   echo userspace > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo <frequency> > /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed    

this is tested with MX93(A1) EVK running 6.1.55_2.2.0 pre-build image.   USB can output test patterns with either one of the setup below: 1. through device node: root@imx93evk:/sys/kernel/debug/usb/ci_hdrc.0# cat role gadget root@imx93evk:/sys/kernel/debug/usb/ci_hdrc.0# echo host > role [ 2672.864083] ci_hdrc ci_hdrc.0: EHCI Host Controller [ 2672.868996] ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 1 [ 2672.893320] ci_hdrc ci_hdrc.0: USB 2.0 started, EHCI 1.00 [ 2672.899314] hub 1-0:1.0: USB hub found [ 2672.909235] hub 1-0:1.0: 1 port detected root@imx93evk:/sys/kernel/debug/usb/ci_hdrc.0# cat role host root@imx93evk:/sys/kernel/debug/usb/ci_hdrc.0# echo 4 > port_test root@imx93evk:/sys/kernel/debug/usb/ci_hdrc.0# echo 3 > port_test root@imx93evk:/sys/kernel/debug/usb/ci_hdrc.0# echo 2 > port_test root@imx93evk:/sys/kernel/debug/usb/ci_hdrc.0# echo 1 > port_test   2. use memtool to program registers for i in $(find /sys -name control | grep usb);do echo on > $i;echo "echo on > $i";done; echo host > /sys/kernel/debug/usb/ci_hdrc.0/role #Offset:184h USB_OTG1 base address: 4C10_0000h base address USB_OTG2 base address: 4C20_0000h Register address Register address：base address+offset $ /unit_tests/memtool 0x4c100184 1 # Force to output Test Packet for Eye Diagram Test $ /unit_tests/memtool 0x4c100184=0x18041215 #Force to output J_STATE $ /unit_tests/memtool 0x4c100184=0x18011215 #Force to output K_STATE $ /unit_tests/memtool 0x4c100184=0x18021215 #Force to output SE0 (host) / NAK (device) $ /unit_tests/memtool 0x4c100184=0x18031215

Hey everyone !! This piece covers how to configure the iMX93EVK board to wake up Cortex A55[ running Linux] from Cortex M33 core[running a bare metal application].    We will be using UART console on Cortex M33 to signal Cortex A55 via RPMSG to wake-up from deep sleep.   This can be done as follows:-   1. Boot iMX93EVK with RPMSG enabled DTB and load M33 binary via UBOOT   After booting to Uboot terminal, set the fdtfile variable to <rpmsg dtb> that will help us enable rpmsg in the kernel.   u-boot=> setenv fdtfile imx93-11x11-evk-rpmsg.dtb u-boot=> setenv bootargs ${jh_clk} ${mcore_clk} console=${console} root=${mmcroot}   then, load the M33 binary from the eMMC partition    u-boot=> fatload mmc 0:1 0x80000000 imx93-11x11-evk_m33_TCM_power_mode_switch.bin 18996 bytes read in 14 ms (1.3 MiB/s)   u-boot=> cp.b 0x80000000 0x201e0000 0x4a34 u-boot=> saveenv Note:-  Do not run the M33 core via bootaux at this point, instead just boot to Linux   u-boot=> boot         2. Starting the Cortex M33 core from Cortex A55[running Linux]   Once linux is up, load the elf of Cortex M33 power mode switch application.   echo ~/power_mode_switch.elf > /sys/devices/platform/imx93-cm33/remoteproc/remoteproc0/firmware   start the M33 core   echo start > /sys/devices/platform/imx93-cm33/remoteproc/remoteproc0/state   On console of Cortex M33 you will see the output as below:-   The log below shows the output of the power mode switch demo in the terminal window: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Start SRTM communication Task 1 is working now #################### Power Mode Switch Task #################### Build Time: Nov 10 2023--15:15:16 Core Clock: 200000000Hz Select the desired operation Press A to enter: Normal RUN mode Press B to enter: WAIT mode Press C to enter: STOP mode Press D to enter: SUSPEND mode Press W to wakeup A55 core Press M for switch M33 Root Clock frequency between OD/ND. Waiting for power mode select.. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~   M33 at this point is ready to wake up the A55 core.     3. Put A55 core to deep sleep and trigger a wakeup from M33 console   To put A55 to deep sleep   echo mem > /sys/power/state you will see something like below on linux console:-     At this point, A55 core is in deep sleep power saving mode. So the A55 console will not respond to any of the key presses. Go on, give it a try 🙂   Now to wake up this core, go to M33 serial console and type 'W'  This will wake up A55 core and you will see the logs denoting that the core has woken up:-   That's it! that's how you exercise UART wake-up functionality on imx93evk. Please feel free to drop any follow-up questions or additional thoughts on this.

Dynamic debug is designed to allow you to dynamically at runtime  enable/disable  kernel code to obtain additional kernel information. Currently, if ``CONFIG_DYNAMIC_DEBUG`` is set, then all ``pr_debug()``/``dev_dbg()`` and ``print_hex_dump_debug()``/``print_hex_dump_bytes()`` calls can be dynamically enabled per-callsite.    

Symptoms   Trying to initialize a repo, for example:  $repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-mickledore -m imx-6.1.36-2.1.0.xml we have the below log: File "/home/username/bin/repo", line 51 def print(self, *args, **kwargs): ^ SyntaxError: invalid syntax   Workaround (1)   The first workaround consist in change the python alternatives (caused when you have installed two or more python versions). NOTE: in my case, the python version that i want to change as first priority is python3.8 $sudo update-alternatives --install /usr/bin/python python /usr/bin/python3.8 1   Then we run: $sudo update-alternatives --config python    To verify if your python priority was changed successfully try: $python --version   You should see the version configured as priority number 1.     Workaround (2)   The workaround is very simple, only we need modify the repo file $ nano ~/bin/repo   and we will change the python interpreter in the first line (from python to python3): ORIGINAL FILE   EDITED FILE   After to do this change, repo will works fine again.     I hope this can helps to you!   Best regards.

  Environment i.MX8MP EVK, SDK2.15   The default rpmsg buffer size in SDK is 512Bytes(16 Bytes header + 496Bytes payload). This knowledge base will try to change the default buffer size in rpmsg framework. Steps:   1.Modify rpmsg payload size in SDK PATH: SDK\evkmimx8mp_rpmsg_lite_str_echo_rtos_imxcm7\rpmsg_config.h     //! RL_BUFFER_PAYLOAD_SIZE //! //! Size of the buffer payload, it must be equal to (240, 496, 1008, ...) //! [2^n - 16]. Ensure the same value is defined on both sides of rpmsg //! communication. The default value is 496U. #define RL_BUFFER_PAYLOAD_SIZE (1008)     2. Modify buffer size in rpmsg linux framework and buffer pool in dts. PATH: drivers/rpmsg/virtio_rpmsg_bus.c            arch/arm64/boot/dts/freescale/imx8mp-evk-rpmsg.dts   Test steps:   Modify the send buffer in imx_rpmsg_tty.c     #define MSG "hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world! hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world! hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!"       Modify buffer limitation in SDK PATH: evkmimx8mp_rpmsg_lite_str_echo_rtos_imxcm7\main_remote.c     /* Globals */ static char app_buf[1024]; /* Each RPMSG buffer can carry less than 512 payload */       Terminal output We can see that the MAX buffer size received in SDK is not limited to 512Bytes     Nameservice sent, ready for incoming messages... Get Message From Master Side : "hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world! hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world! hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!hello world!" [len : 674]       If we use a larger buffer like 2022 Bytes, we will see error when driver load.     [ 2673.447384] imx_rpmsg_tty virtio0.rpmsg-virtual-tty-channel-1.-1.30: message is too big (2022) [ 2673.456271] imx_rpmsg_tty virtio0.rpmsg-virtual-tty-channel-1.-1.30: rpmsg_send failed: -90 [ 2673.465556] imx_rpmsg_tty virtio0.rpmsg-virtual-tty-channel-1.-1.30: rpmsg_dev_probe: failed: -90 [ 2673.474496] imx_rpmsg_tty: probe of virtio0.rpmsg-virtual-tty-channel-1.-1.30 failed with error -90          

We are pleased to announce that Config Tools for i.MX v15.0 are now available. Downloads & links To download the installer for all platforms, please login to our download site via:  https://www.nxp.com/design/designs/config-tools-for-i-mx-applications-processors:CONFIG-TOOLS-IMX Please refer to  Documentation  for installation and quick start guides. For further information about DDR config and validation, please go to this  blog post. Release Notes Full details on the release (features, known issues...)Version 15.0 • The product is based on Eclipse 2023-06 TEE – Setting a security level for a special three-state model is improved. Pins – Validation to ensure that elements can be configured by the selected core is added. – Rows are sorted in the Peripheral Signals routing dialog. – A connected pins column in External User Signals always shows the pin's full name. – The missing scroll bar in the External User Signals view is fixed. Clocks – Support for multicore code generation is added. – Global configuration elements now support a tree structure and can be categorized. – Fractional PLL now supports a custom range and negative numerator. – Scrolling in the clock diagram by pressing the mouse wheel (drag and drop) is supported. DCD – The issue with the code generation that stopped working after the drag and drop of a group is fixed.  

i.MX6 Series - Crystal Drive Level guidance; includes calculator.  

In the IMX8MM SDK unfortunately we cannot find any example about of use a GPIO as an input with interrupt.  To use a GPIO as input with interrupt we need to keep in mind how the GPIO IRQs works in the ARM Cortex M4.   We can find in Table 7-2 (CM4 Interrupt Summary) of IMX8MMRM (IMX8MM Reference Manual) the GPIOs IRQs are divided by two parts:     Combined interrupt indication for GPIOn signal 0 throughout 15  Combined interrupt indication for GPIOn signal 16 throughout 31    This basically means, the pines of GPIOn from 0 to 15 are handled by Combined interrupt indication for GPIOn signal 0 throughout 15 and the pines from 16 to 31 are handled by Combined interrupt indication for GPIOn signal 16 throughout 31.    In SDK we can find these definitions in:  <SDK root>/devices/MIMX8MM6/MIMX8MM6_cm4.h (Remember this is for IM8MM SDK)    In this example I will use GPIO5_IO12 (ECSPI2_MISO) as Input with IRQ and GPIO5_IO11 (ECSPI_MOSI) as Output of IMX8MM-EVK. I will connect the Output to the Input and will see the behavior of the IRQ in Rising and Falling edge.    For this example I will connect ECSPI2_MOSI (GPIO5_IO11) to ECSPI_MISO (GPIO5_IO12):   See the below definitions:   #define IN_GPIO   GPIO5  This define the GPIO base of the IN pin  #define IN_GPIO_PIN  12u  This define the pin number (for in)  #define IN_IRQ  GPIO5_Combined_0_15_IRQn  This define the IRQ number (72 in this case)  #define GPIO_IRQ_HANDLER  GPIO5_Combined_0_15_IRQHandler  This is a "pointer" to function that will handle the interrupt  #define IN_NAME  "IN GPIO5_IO12"  This is only a name or description for the pin    See below definitions:    #define OUT_GPIO  GPIO5  This is the GPIO base of OUT pin  #define OUT_GPIO_PIN  11u  This define the pin number (for out)  #define OUT_NAME  "OUT GPIO5_IO11"  This is only a name or description for the pin      Now the below section is the IRQ handler (which was defined before)😞   The GPIO_ClearPinsInterruptFlags(IN_GPIO, 1u << IN_GPIO_PIN); refers to GPIOx_ISR register:      For this example, the IRQ Handler will print "IRQ detected ............" in each interrupt.    We will create two different GPIOs config, one for Output and other one for Input with IRQ Falling edge:    Then configure the GPIOs and IRQ:     EnableIRQ refers to enable the 72 IRQ.   GPIO_PortEnableInterrupts refers to GPIOx_IMR: Finally, the example put the out GPIO5_IO11 in High state and then in low state many. First the IRQ is configured as Falling edge, then as Rising edge.     I will attach the complete source file.    To compile it you can use ARMGCC toolchain directly, but I like to use VSCode with MCUXpresso integration.  Once, when you have your .bin file (in my case igpio_led_output.bin) you can load to board with UUU tool: In your Linux machine: sudo uuu -b fat_write igpio_led_output.bin mmc 2:1 gpio.bin In U-boot board: u-boot=> fastboot 0   Then, when the .bin file was loaded, you can load to the CORTEX M4 in U-boot whit: u-boot=> fatload mmc 2:1 ${loadaddr} gpio.bin 7076 bytes read in 14 ms (493.2 KiB/s) u-boot=> cp.b 0x80000000 0x7e0000 0x10000 u-boot=> bootaux 0x7e0000 ## No elf image ar address 0x007e0000 ## Starting auxiliary core stack = 0x20020000, pc = 0x1FFE02CD... u-boot=>   NOTE: You can load the binary to cortex m4 with Custom bootscripts for practicity.   Once the binary loaded in M4 core you should see in seria terminal this logs (Remember GPIO5_IO11 and GPIO5_IO12 must be connected to get the same logs):    And the logs when you disconnect the GPIO5_IO11 and GPIO5_IO12 in execution time:  🔴Disconnection (Red color) 🔵Reconnection (Blue color)   I hope this can helps.     Best regards!    Salas. 

some customers doesn't have any issue on old bsp, but have bring up issue on new 6.1 bsp, this article is about this and how to fix this

Hello there. Here is a good way to use U-boot in an efficient way with custom scripts. The bootscript is an script that is automatically executed when the boot loader starts, and before the OS auto boot process. The bootscript allows the user to execute a set of predefined U-Boot commands automatically before proceeding with normal OS boot. This is especially useful for production environments and targets which don’t have an available serial port for showing the U-Boot monitor. This information can be find in U-Boot Reference Manual.   I will take the example load a binary file in CORTEX M4 of IMX8MM-EVK. In my case, I have the binary file in MMC 2:1 called gpio.bin and I will skip those steps because that is not the goal.   First, you need the u-boot-tools installed in your Linux machine: sudo apt install u-boot-tools   That package provide to us the tool mkimage to convert a text file (.src, .txt) file to a bootscript file for U-Boot.   Now, create your custom script, in this case a simple script for load binary file in Cortex M4: nano mycustomscript.scr  and write your U-Boot commands: fatload mmc 2:1 0x80000000 gpio.bin cp.b 0x80000000 0x7e0000 0x10000 bootaux 0x7e0000   Now we can convert the text file to bootscript with mkimage. Syntax: mkimage -T script -n "Bootscript" -C none -d <input_file> <output_file> mkimage -T script -n "Bootscript" -C none -d mycustomscript.scr LCM4-bootscript   This will create a file called LCM4-bootscript (Or as your called it).   A way to load this bootscript file to U-Boot is using the UUU tool, in U-Boot set the device in fastboot with command: u-boot=> fastboot 0 Then in linux with the board connected through USB to PC run the command: sudo uuu -b fat_write LCM4-bootscript mmc 2:1 LCM4-bootscript   Now we have our bootscript in U-Boot in MMC 2:1.   Finally, we can run the bootscript in U-Boot: u-boot=> load mmc 2:1 ${loadaddr} LCM4-bootscript 158 bytes read in 2 ms (77.1 KiB/s) u-boot=> source ${loadaddr} ## Executing script at 40400000 6656 bytes read in 5 ms (1.3 MiB/s) ## No elf image at address 0x007e0000 ## Starting auxiliary core stack = 0x20020000, pc = 0x1FFE02CD...   And the Cortex M4 booted successfully:    I hope this can helps to you.   Best regards.   Salas.  

This document intends to provide an overview of the i.MX8 Boot process and walk you through the process of creating a bootable image.   Boot process Coming out of a reset state the i.MX8 ROM (firmware that is stored in non-volatile memory of the i.MX8) reads the boot mode pins to determine the boot media/device that will be used. The i.MX8 can boot out of the following boot devices: eMMC/SD card FlexSPI Flash NAND Serial Download Protocol (USB) - This is used in manufacturing mode to bring-up a board by downloading an image to RAM and then flashing the on-board boot device.   The following table indicates the available options on a i.MX8QXP, the i.MX8 reads the boot mode pads and based in the configuration selects the desired boot device.   Once the boot device has been identified, ROM configures the boot media and attempts to read the image from a predefined address in the boot device, the following table shows the addresses where the image is expected to be on different boot devices. ROM loads data from the predefined addresses above (depending on the selected boot device) to the System Controller Unit (SCU) internal memory (tightly coupled memory) and parses it to find the image container. It can also boot by downloading an image through USB.   The image container has all the information needed to load all the images to the system, the first images that get loaded are the System Controller Firmware (SCFW) and Security Controller Firmware (SECO). The SECO FW needs to be loaded to refresh the watchdog timer (kick the dog) in the device, if the SECO FW is not loaded before the watchdog expires the device will reset, this usually happens when the device fails to fetch a valid image from the boot media.   Once the SCFW is loaded, ROM jumps to it and starts executing it. The SCFW then initializes the DDR and starts loading the images for the Cortex-M4 (optional) and the Cortex-A cores (optional). Once the images are loaded to their destination memory the SCFW boots the cores and sets them in their start address.   Creating a bootable image As a recap a bootable image is comprised of as minimum the System Controller Firmware and the Security Controller Firmware, optionally it can contain images for the Cortex M4 cores (if more than one available as in the case of QM devices) and Cortex A cores. It is possible to boot an image that only contains the SCFW and SECO FW, this could be useful in the first stages of porting the SCFW to the target board. It is also possible to boot an image with only the Cortex-M4 image (baremetal, FreeRTOS, AutoSAR...), only the Cortex-A image (U-boot or any bootloader) or both Cortex-M4 and Cortex-A images.   Mkimage tool The tool in charge of merging all these images and creating a bootable image for the i.MX8 is called mkimage, and can be obtained in source form in the following repository: https://github.com/nxp-imx/imx-mkimage mkimage is only supported in Linux So the first step is to clone the mkimage repository into our machine and checkout the latest branch, at the time of writing this document the latest release is 4.14.98_02: git clone https://source.codeaurora.org/external/imx/imx-mkimage cd imx-mkimage git checkout imx_4.14.98_2.0.0_ga‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ You should now be able to see the following folders:   Getting the SCFW Now that you have the mkimage tool you need some actual images to work with, if you are using a custom board you might need to port the SCFW and DDR configuration files for it (depending on how close it follows NXP's reference board).   The following is a compendium of documents on the basics of the SCFW and how to build it from scratch you can go there if you need help getting started with the porting process: https://community.nxp.com/docs/DOC-342654   If you are trying this on one of NXP's reference board you can use a pre-built SCFW binary, this can be obtained through the building process of the Yocto project or by downloading the porting kit and following these steps: Dowload SCFW binaries for release 4.14.98_02 here. chmod a+x imx-sc-firmware-1.2.bin ./imx-sc-firmware-1.2.bin‍‍‍‍‍‍‍‍‍‍ You will prompted to accept a license agreement and after that the binaries will be extracted:   Getting the SECO FW The Security Controller Firmware is only distributed in binary form and can be obtained from the NXP website. Download SECO FW binaries for release 4.14.98_02 here. chmod a+x firmware-imx-8.1.bin ./firmware-imx-8.1.bin‍‍‍‍‍‍‍‍‍‍ You will prompted to accept a license agreement and after that the binaries will be extracted: The SECO FW is under firmware/seco mx8qm-ahab-container.img -----> SECO FW for QM devices mx8qx-ahab-container.img ------> SECO FW for QXP devices   Getting an image for the Cortex-M4 The image for the Cortex-M4 can be generated using the SDK: https://mcuxpresso.nxp.com/en/select Just select the device you are working with and click Build MCUXpresso SDK, then you will prompted to select your IDE and host. Click on Download SDK and a compressed file containing the SDK will be dowloaded to your computer. Now you only need to uncompress the file and follow the steps in the getting started document to generate the image.  The getting started document includes steps to setup the toolchain and build an image for the M4. An M4 binary for the QM and QXP MEKs is also attached in this document, the example outputs a hello world message on the M4 terminal. Getting an image for the Cortex-A  The bootloader for the Cortex-A cores can be obtained through the Yocto BSP: The steps on generating the image for the 4.14.98 release can be found here: https://www.nxp.com/webapp/Download?colCode=imx-yocto-L4.14.98_2.0.0_ga    Some more details on the Yocto BSP can be found here: https://community.nxp.com/docs/DOC-94849   All the required binaries to create a bootable image for the Cortex-A cores on the MEK platforms are attached here.   Building a bootable image Once all the required pieces have been built/obtained, the bootable image can be created. The SCFW, SECO FW and respective Cortex-M4/A images need to be copied to the folder for the target device, i.e. if you are building an image for an i.MX8QX variant copy the binaries for that variant to its folder:   Here is a list of the required files to build a bootable image: scfw_tcm.bin -------------------------------------------- System Controller Firmware binary for the target board mx8qm(qx)-ahab-container.image ---------------- Security Controller Firmware for the QM or QXP variants bl31.bin --------------------------------------------------- ARM Trusted Firmware binary (Required if using u-boot with ATF) Only needed to create Cortex-A image with u-boot u-boot.bin ------------------------------------------------ U-boot binary (optional) m4_image ----------------------------------------------- M4 binary image, the QM variant has 2 Cortex-M4s and in this case to M4 binaries might be required (optional)   Once the required binaries have been copied to the desired variant folder (QXP or QM in this example), you are ready to start building some images.   All the targets for building different images are defined on the soc.mak file contained in each folder, this file contains different examples for creating a lot of the supported bootable images.   Creating a SCFW only image The target used to create a SCFW only image is flash_b0_scfw and it is defined under the soc.mak file of each variant. To invoke this target for QXP from the imx-mkimage directory: make SOC=iMX8QX flash_b0_scfw‍‍‍ To invoke this target for QM from the imx-mkimage directory: make SOC=iMX8QM flash_b0_scfw‍‍‍   The target definition for flash_b0_scfw can be seen below. Definition for QXP: flash_scfw flash_b0_scfw: $(MKIMG) mx8qx-ahab-container.img scfw_tcm.bin ./$(MKIMG) -soc QX -rev B0 -dcd skip -append mx8qx-ahab-container.img -c -scfw scfw_tcm.bin -out flash.bin ‍‍‍‍‍‍‍‍ Definition for QM: flash_b0_scfw: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin ./$(MKIMG) -soc QM -rev B0 -dcd skip -append mx8qm-ahab-container.img -c -scfw scfw_tcm.bin -out flash.bin‍‍‍‍‍‍   Creating a Cortex-A image only The target used to create a Cortex-A image only is called flash_b0. To invoke this target for QXP from the imx-mkimage directory: make SOC=iMX8QX flash_b0 ‍‍‍ To invoke this target for QM from the imx-mkimage directory: make SOC=iMX8QM flash_b0‍ ‍‍‍ The target definition for flash_b0 can be seen below. Definition for QXP:   flash flash_b0: $(MKIMG) mx8qx-ahab-container.img scfw_tcm.bin u-boot-atf.bin ./$(MKIMG) -soc QX -rev B0 -append mx8qx-ahab-container.img -c -scfw scfw_tcm.bin -ap u-boot-atf.bin a35 0x80000000 -out flash.bin‍‍‍‍ Definition for QM:   flash_b0: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin u-boot-atf.bin ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c -scfw scfw_tcm.bin -ap u-boot-atf.bin a53 0x80000000 -out flash.bin‍‍‍‍   Creating a Cortex-M4 image only The target used to create a Cortex-m4 image only is called flash_b0_cm4 on QXP and QM has different targets since there are two M4s available in the system. To invoke this target for QXP from the imx-mkimage directory: make SOC=iMX8QX flash_b0_cm4‍‍ To invoke this target for QM from the imx-mkimage directory: // For Cortex-M4_0 only make SOC=iMX8QM flash_b0‍_cm4‍_0 // For Cortex-M4_1 only make SOC=iMX8QM flash_b0‍_cm4‍_1 // For both Cortex-M4_0 and Cortex-M4_1 make SOC=iMX8QM flash_b0‍_m4‍s_tcm ‍‍‍‍‍‍‍‍‍‍‍‍‍   The target definition for flash_b0_cm4 can be seen below. Definition for QXP: flash_cm4 flash_b0_cm4: $(MKIMG) mx8qx-ahab-container.img scfw_tcm.bin m4_image.bin ./$(MKIMG) -soc QX -rev B0 -append mx8qx-ahab-container.img -c -scfw scfw_tcm.bin -p1 -m4 m4_image.bin 0 0x34FE0000 -out flash.bin‍‍‍‍ Definitions for QM: flash_b0_cm4_0: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin m4_image.bin ./$(MKIMG) -soc QM -rev B0 -dcd skip -append mx8qm-ahab-container.img -c -scfw scfw_tcm.bin -p1 -m4 m4_image.bin 0 0x34FE0000 -out flash.bin flash_b0_cm4_1: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin m4_image.bin ./$(MKIMG) -soc QM -rev B0 -dcd skip -append mx8qm-ahab-container.img -c -scfw scfw_tcm.bin -p1 -m4 m4_image.bin 1 0x38FE0000 -out flash.bin flash_b0_m4s_tcm: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin m40_tcm.bin m41_tcm.bin ./$(MKIMG) -soc QM -rev B0 -dcd skip -append mx8qm-ahab-container.img -c -scfw scfw_tcm.bin -p1 -m4 m40_tcm.bin 0 0x34FE0000 -m4 m41_tcm.bin 1 0x38FE0000 -out flash.bin‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍   The examples above are for M4 images booting from TCM, the M4 is capable of booting and executing from DDR and it is also able to XIP (execute in place) from SPI memory, for examples on this targets please look at the soc.mak for the desired variant. Creating an image with both Cortex-A and Cortex-M4 images The target used to create an image with software for all the cores is called flash_linux_m4. To invoke this target for QXP from the imx-mkimage directory: make SOC=iMX8QX flash_linux_m4‍ ‍ To invoke this target for QM from the imx-mkimage directory: make SOC=iMX8QM flash_linux_m4‍ ‍ The target definition for flash_linux_m4 can be seen below. Definition for QXP: flash_linux_m4: $(MKIMG) mx8qx-ahab-container.img scfw_tcm.bin u-boot-atf.bin m4_image.bin ./$(MKIMG) -soc QX -rev B0 -append mx8qx-ahab-container.img -c -flags 0x00200000 -scfw scfw_tcm.bin -ap u-boot-atf.bin a35 0x80000000 -p3 -m4 m4_image.bin 0 0x34FE0000 -out flash.bin‍‍   Definition for QM: flash_linux_m4: $(MKIMG) mx8qm-ahab-container.img scfw_tcm.bin u-boot-atf.bin m4_0_image.bin m4_1_image.bin ./$(MKIMG) -soc QM -rev B0 -append mx8qm-ahab-container.img -c -flags 0x00200000 -scfw scfw_tcm.bin -ap u-boot-atf.bin a53 0x80000000 -p3 -m4 m4_0_image.bin 0 0x34FE0000 -p4 -m4 m4_1_image.bin 1 0x38FE0000 -out flash.bin‍‍     Flash image This will create a bootable image named flash.bin, to flash this image to the SD card and boot it on your MEK simply do: sudo dd if=iMX8QX/flash.bin of=/dev/mmcblkX bs=1k seek=32‍‍‍‍‍‍‍ If the desired target is a QM variant change if=iMX8QX... to if=iMX8QM. Then match your SD card device on "of=/dev/mmcblkX" you can see how your SD card enumerates by typing lsblk on your console before and after inserting your SD card. Remember from the information above that the i.MX8 will search for the image at 32k on the SD card, that is why we are flashing it there. For more examples please look at the soc.mak file, it includes examples for different boot media (NAND/QSPI) as well as different configurations and usage.   Additional resources Reference Manual Chapter 5 System Boot SCFW API and Port document imx-mkimage README System Controller Firmware 101 

Symptoms   On i.MX8MP, when inputting a 80% duty, 0.4V-1.8V, 3KHz square wave, we observed that the system may hang. We also tested i.MX8MN and i.MX8MM and observed the same phenomenon. In i.MX8MN RM, there's a note in GPC chapter:     We believe that the issue described in this note exists not only in the iMX8MN, but also in the iMX8MP and iMX8MM. Meanwhile, there is not only a problem with power down in this issue, but also a problem with wait mode. Diagnosis   In debugging, we find that avoiding accessing LPCR_A53_AD register in imx_set_cluster_powerdown can fix the issue. So we think that due to frequently power up/down of cores, cores have chances failed to power up. When the IRQ behavior become more complex, because the IRQ is an async event, it will come in any time. if the wait mode is enabled, in some conner case, the GPC internal LPM mode state machine will run into problem, then lead to system failure. Solution   1. A workaround patch that bypass the wait mode setting during the cpuidle.. See the patch attached. 2. Will add the Note about "SCU power down should not be enabled in wait mode" to i.MX8MP and i.MX8MM RM. 3. Will try to identify this issue into errta document, ticket TKT0632147.

Hardware i.MX 93 EVK​ TFT LCD 480x272 RGB888 (NV3047E, parallel)​ Condition A55 off​ DDR self-refresh​ OCRAM for framebuffer, TCM for code/data​ LCDIF on with parallel interface​ M33 update panel content each second​ 255KB single frame buffer(RGB565) (fit in OCRAM: 0x20480000 ~ 0x204DFFFF)​ Code Bitbucket：ssh://git@bitbucket.sw.nxp.com/mpucnse/imx93-cm33-usecase.git​ Branch: imx93_sdk_2.14.1-lcd_on_ocram​ Demo code: imx93-cm33-usecase/boards/mcimx93evk/demo_apps/lcd_on_ocram​ DTS: imx93-cm33-usecase/boards/mcimx93evk/demo_apps/lcd_on_ocram/dts​ Working Flow   ​Test Flow In uboot console,​ setenv mmcargs $mmcargs clk-imx93.mcore_booted​ setenv fdtfile imx93-11x11-evk-lcd_panel.dtb​ fatload mmc 1:1 0x80000000 sdk20-app.bin;cp.b 0x80000000 0x201e0000 0x10000;bootaux 0x1ffe0000 0​ boot​ In kernel console,​ echo mem > /sys/power/state​ start the power test Power Consumption SoC power: 94.4mW​ VDD_SOC@0.8V​ CM33@100MHz​ CM33@100MHz​ A55 suspend​ DDR retention​ WAKEUPMIX off​ NICMIX and MEDIAMIX on​  ​  

This is a simple document for recording some known-how and tips for building up the Windows 10 IoT development environment for i.MX platform. It can only be used as a complement for official document in BSP package (Guide/Release Note/etc.). Applicable for: Windows 10 IoT, i.MX BSP v1.4.1 (date to Nov/2023) Please refer to the PDF attached.