Platform: Ubuntu 12.04 Board: Freescale MCIMX6Q-SDP  and  MCIMX-LVDS1 Screen BSP: L3.0.35_4.1.0_ER_SOURCE_BSP Other device: PC , One Router, 3 Network Cable and 2 usb-otg lines The  platform is as follow: Boot form NFS is very convenient in porting and debugging, and will value us much time. If the customers have modified the kernel and rebuild the kernel to generate the uImage running on board, he can directly download the uImage to the board by TFTP network. It is fast and can avoid the normal operation ,  first customers need to copy the images to the mfgtool specified directory and download the u-boot, uImage and file sytem again to the flash device in board, and then change to boot up mode to boot up the board. If customers are doing debug this operation will waste lot of time. So use the NFS is vey convenient. Beyond this, in the target board customers can also read the files and content in host machine. In a word, use NFS it will help save much time and also convenient. So the follows is introduce and show how to set NFS and then boot up the board. 1 Preparation (1)Build the BSP Build up the L3.0.35_4.1.0_ER_SOURCE_BSP use LTIB on the Ubuntu12.04, you can refer to our user guide document here no details. The u-boot, uImage and file system are all under the directory of litb. Boot up from NFS, so when build uImage some items are needed, here you can see the build details in the section of  Setting Target Linux Image to use NFS in this articel. (2)Download the u-boot to the target board Use the mfgtool Mfgtools-Rel-4.1.0_130816_MX6Q_UPDATER to download the u-boot to the SD card of MCIMX6Q-SDP board or use dd command to write the u-boot to SD card.( By the way, writing to the EMMC is also OK) 2 Setting the NFS Environment Set host machine 1 - Install NFS Service on host typing:     $sudo apt-get install nfs-kernel-server       2 - Create symbolic link to ltib/rootfs     $sudo ln -s <ltib instalation folder>/rootfs /tftpboot/rootfs       3 - Setup exports typing:     $sudo gedit /etc/exports       and add the following line:     /tftpboot/rootfs/ *(rw,no_root_squash,no_subtree_check,async) 4 - Restart the NFS server:     $sudo /etc/init.d/nfs-kernel-server restart       Now the host is ready to use NFS Setting Target Linux Image to use NFS       1. Run LTIB configuration by typing: $cd <ltib instalation folder>       $./ltib -c       2. On first page menu, go to "Target Image Generation -> Options"       3. Select the option NFS only and exit LTIB configuration to compile with the new configuration. 4. LTIB should start new compiling and create a new Linux image on /<ltib instalation folder>/rootfs/boot/uImage      5. Copy the created image on /<ltib instalation folder>/rootfs/boot/uImage to /tftpboot/uImage 6. The system is ready to run with NFS. The root file system on target will be located on host on /<ltib instalation folder>/rootfs/ 3 Setting the u-boot command line (1)Download the u-boot to the target board fist according to the section 1 (2) Download the u-boot to the target board. Then give the power to the board, boot up board, u-boot boot up. (2)Configuration the Network Configure the Network and IP , to make the target board and the host machine IP are in the local area network of Router. (3)Set the u-boot command line As follow is my setting for you to refer to : 4 Boot up the board Running the “run bootcmd” after setting the u-boot parameters then boot up the kernel and file system. We can see that the board download the uImage by the TFTP from host machine, then boot up the kernel and finally mount the NFS in the kernel. As follows is the details: Downloading the uImage success and boot up kernel: Input root and access the system. Test: Create a new file in the host machine directory, you can see in the next picture: Then open the target board, in the terminal go to the same directory  in the unit_test we can see the same name. So as we can see in the above operation we can see it is very convenient and fast use the NFS. It will help save time and speed the development time.

As we haven't provided a guide with steps that implement the Linux OS encryption and signature for i.MX9x products so far. So, the document provides the steps for that. For details related to how to encrypt and sign a bootloader image, please have a reference to This Guide 

BSP: L5.15.5_1.0.0 Platform: i.MX8MPlus EVK Background   The function lpddr4_mr_read in BSP always return zero and this casue the customer can't use it to read MR registers in DRAM. This is a simple demo for reading MR registers. Patch Code   diff --git a/arch/arm/include/asm/arch-imx8m/ddr.h b/arch/arm/include/asm/arch-imx8m/ddr.h index 0f1e832c03..fd68996a23 100644 --- a/arch/arm/include/asm/arch-imx8m/ddr.h +++ b/arch/arm/include/asm/arch-imx8m/ddr.h @@ -721,6 +721,8 @@ int wait_ddrphy_training_complete(void); void ddrphy_init_set_dfi_clk(unsigned int drate); void ddrphy_init_read_msg_block(enum fw_type type); +unsigned int lpddr4_mr_read(unsigned int mr_rank, unsigned int mr_addr); + void update_umctl2_rank_space_setting(unsigned int pstat_num); void get_trained_CDD(unsigned int fsp); diff --git a/board/freescale/imx8mp_evk/spl.c b/board/freescale/imx8mp_evk/spl.c index 33bbbc09ac..85e40ffbbe 100644 --- a/board/freescale/imx8mp_evk/spl.c +++ b/board/freescale/imx8mp_evk/spl.c @@ -150,6 +150,40 @@ int board_fit_config_name_match(const char *name) return 0; } #endif +void lpddr4_get_info() +{ + int i = 0, attempts = 5; + + unsigned int ddr_info = 0; + unsigned int regs[] = { 5, 6, 7, 8 }; + + for(i = 0; i < ARRAY_SIZE(regs); i++){ + unsigned int data = 0; + data = lpddr4_mr_read(0xF,regs[i]); + ddr_info <<= 8; + ddr_info += (data & 0xFF); + switch (i) + { + case 0: + printf("DRAM INFO : Manufacturer ID = 0x%x",ddr_info); + if(ddr_info & 0Xff) + printf(", Micron\n"); + break; + case 1: + printf("DRAM INFO : Revision ID1 = 0x%x\n",ddr_info); + break; + case 2: + printf("DRAM INFO : Revision ID2 = 0x%x\n",ddr_info); + break; + case 3: + printf("DRAM INFO : I/O Width and Density = 0x%x\n",ddr_info); + break; + default: + break; + } + } + +} void board_init_f(ulong dummy) { @@ -187,6 +221,8 @@ void board_init_f(ulong dummy) /* DDR initialization */ spl_dram_init(); + + lpddr4_get_info(); board_init_r(NULL, 0); } diff --git a/drivers/ddr/imx/imx8m/ddrphy_utils.c b/drivers/ddr/imx/imx8m/ddrphy_utils.c index 326b92d784..f45eeaf552 100644 --- a/drivers/ddr/imx/imx8m/ddrphy_utils.c +++ b/drivers/ddr/imx/imx8m/ddrphy_utils.c @@ -194,8 +194,15 @@ unsigned int lpddr4_mr_read(unsigned int mr_rank, unsigned int mr_addr) tmp = reg32_read(DRC_PERF_MON_MRR0_DAT(0)); } while ((tmp & 0x8) == 0); tmp = reg32_read(DRC_PERF_MON_MRR1_DAT(0)); - tmp = tmp & 0xff; reg32_write(DRC_PERF_MON_MRR0_DAT(0), 0x4); + + while (tmp) { //try to find a significant byte in the word + if (tmp & 0xff) { + tmp &= 0xff; + break; + } + tmp >>= 8; + } return tmp; }     Test Result  

Two IPUs are supported in i.MX6Q SoC, each IPU supports 1920x1080 resolution, and 4 kinds of interfaces on i.MX6Q PADs can be used to connect display devices: HDMI, Digital RGB24, LVDS1+LVDS2, MIPI DSI. In the documents, we will discuss how to expand VGA port with digital RGB and realize dual-display via HDMI & VGA, The solution has been validated on Android4.2.2 and Android4.4.2 BSP released by NXP. 1.  Expanding VGA port based on digital RGB24 interface with ADV7125 Schematic is in attachments. 2. Configurations of envionment variables in u-boot The following settings are for booting via NFS, users can adjust them to boot via Flash on board. setenv ipaddr 192.168.1.103 setenv serverip 192.168.1.102 setenv gateway 192.168.1.1 setenv ethaddr 00:04:9f:00:ea:d3 setenv bootargs_base 'setenv bootargs console=ttymxc0,115200' setenv bootargs_android 'setenv bootargs ${bootargs} init=/init androidboot.console=ttymxc0 androidboot.hardware=freescale' setenv bootargs_nfs 'setenv bootargs ${bootargs} ip=${ipaddr}:${serverip}:${gateway}:${netmask}::eth0 off root=/dev/nfs nfsroot=${serverip}:${nfsroot}' setenv bootargs_disp 'setenv bootargs ${bootargs} video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24,bpp=32 video=mxcfb1:dev=lcd,1920x1080M@60,if=RGB24,bpp=32 video=mxcfb2:off fbmem=32M vmalloc=400M' setenv bootcmd_net 'run bootargs_base bootargs_android bootargs_nfs bootargs_disp;tftpboot ${loadaddr} uImage;bootm' 3. Configurations in BSP file (1)IOMUX of DISP0 port (in header file)     MX6Q_PAD_DI0_DISP_CLK__IPU1_DI0_DISP_CLK,     MX6Q_PAD_DI0_PIN15__IPU1_DI0_PIN15,        /* DE */     MX6Q_PAD_DI0_PIN2__IPU1_DI0_PIN2,        /* HSync */     MX6Q_PAD_DI0_PIN3__IPU1_DI0_PIN3,        /* VSync */     MX6Q_PAD_DISP0_DAT0__IPU1_DISP0_DAT_0,     MX6Q_PAD_DISP0_DAT1__IPU1_DISP0_DAT_1,     MX6Q_PAD_DISP0_DAT2__IPU1_DISP0_DAT_2,     MX6Q_PAD_DISP0_DAT3__IPU1_DISP0_DAT_3,     MX6Q_PAD_DISP0_DAT4__IPU1_DISP0_DAT_4,     MX6Q_PAD_DISP0_DAT5__IPU1_DISP0_DAT_5,     MX6Q_PAD_DISP0_DAT6__IPU1_DISP0_DAT_6,     MX6Q_PAD_DISP0_DAT7__IPU1_DISP0_DAT_7,     MX6Q_PAD_DISP0_DAT8__IPU1_DISP0_DAT_8,     MX6Q_PAD_DISP0_DAT9__IPU1_DISP0_DAT_9,     MX6Q_PAD_DISP0_DAT10__IPU1_DISP0_DAT_10,     MX6Q_PAD_DISP0_DAT11__IPU1_DISP0_DAT_11,     MX6Q_PAD_DISP0_DAT12__IPU1_DISP0_DAT_12,     MX6Q_PAD_DISP0_DAT13__IPU1_DISP0_DAT_13,     MX6Q_PAD_DISP0_DAT14__IPU1_DISP0_DAT_14,     MX6Q_PAD_DISP0_DAT15__IPU1_DISP0_DAT_15,     MX6Q_PAD_DISP0_DAT16__IPU1_DISP0_DAT_16,     MX6Q_PAD_DISP0_DAT17__IPU1_DISP0_DAT_17,     MX6Q_PAD_DISP0_DAT18__IPU1_DISP0_DAT_18,     MX6Q_PAD_DISP0_DAT19__IPU1_DISP0_DAT_19,     MX6Q_PAD_DISP0_DAT20__IPU1_DISP0_DAT_20,     MX6Q_PAD_DISP0_DAT21__IPU1_DISP0_DAT_21,     MX6Q_PAD_DISP0_DAT22__IPU1_DISP0_DAT_22,     MX6Q_PAD_DISP0_DAT23__IPU1_DISP0_DAT_23,     MX6Q_PAD_NANDF_D4__GPIO_2_4,        /* ADV7125 Power on / off (2) Frame buffer static struct ipuv3_fb_platform_data qcorein_fb_data[] = { /*    {     .disp_dev = "ldb",     .interface_pix_fmt = IPU_PIX_FMT_RGB666,     .mode_str = "LDB-WXGA",     .default_bpp = 16,     .int_clk = false,     .late_init = false,     }, */     {     .disp_dev = "hdmi",     .interface_pix_fmt = IPU_PIX_FMT_RGB24,     .mode_str = "1920x1080M@60",     .default_bpp = 32,     .int_clk = false,     .late_init = false,     },     {     .disp_dev = "lcd",     .interface_pix_fmt = IPU_PIX_FMT_RGB24,     .mode_str = "1920x1080",     .default_bpp = 32,     .int_clk = false,     }, }; (3) Settings about IPUs /* HDMI -- IPU1_DI0 */ static struct fsl_mxc_hdmi_core_platform_data hdmi_core_data = {     .ipu_id = 1,     .disp_id = 1, }; /* RGB24 DISP0 LCD(Here is RGB24-->VGA via ADV7125 -- IPU0_DI0 */ static struct fsl_mxc_lcd_platform_data lcdif_data = {     .ipu_id = 0,     .disp_id = 0,     .default_ifmt = IPU_PIX_FMT_RGB24, }; (4) Adding LCD data in board_init() funtion static void __init mx6_qcorein_board_init(void) { .... imx6q_add_lcdif(&lcdif_data); ... } (5) Adding mxc_lcd.c driver to linux kernel When using make menuconfig to configure kernel, don't forget to add LCD driver to kernel.  Note: If users are using other version of android BSP, she can do porting according to above thinking. Weidong Sun NXP TIC team

Two year ago we have developed a 16 bit ETM adaptor to connect our PowerTrace II module with our AUTOFOCUS II preprocessor : TRACE32® Chip Support and Configurations for IMX6QUAD This adaptor is connected on the EDGE connector of the SABRE Automotive Industry board from Freescale and provide a MICTOR 38 connector compatible with 16 bit maximum ETM size. This is the maximum ETM size supported by iMX6. The maximum Trace clock frequency riched is 132 Mhz, which provide enough bandwidth to trace a full ANDROID running on Quad Core iMX6 !!! and it works perfectly. with Lauterbach tools you can debug completely Linux kernel and driver and full ANDROID support using our dalvik awareness that show you the complete call stack from low level system linux call to high level JAVA code. this adaptor is already in use on several customer from us, with perfect result. TRACE32 can now display all the code executed by the iMX6 Quad for each core, with no limitation on time recording. Linux task switch timing, profiling function, MIPS information, Detailed Tree function etc ... more detail here : TRACE32® Trace-based Profiling here below a small example of what you can see : here below the board, and schematic. in case you want the full schematic for this adaptor, please contact me, i can then provide it for free ... if you buy some Lauterbach tools 😉 Jean-Pierre Paradiso Sales Manager http://www.lauterbach.com/frames.html?tutorials.html PS : we are also developping a new ETM adapter compatible with our partner DAVE (DAVE Embedded Systems ) that develop very nice eval board on iMX6 called AXEL EVB will be available soon through the official DAVE  distributor in France : Cynetis

Booting Linux Directly from SD/MMC Card     You can create a self-bootable SD or MMC card with Linux.     This tutorial describes how to create a complete Linux system (bootloader + Linux kernel + root file system) that boots from SD/MMC card.     This is very useful for people willing to demonstrate several Linux images that can be self-contained in SD/MMC cards. Flashing RedBoot on MMC using ATK     To boot Linux from a SD card, the first thing to do is to program the bootloader to the card. For this, click on the link below:     I.MX35 PDK Board Flashing SDCard Flashing RedBoot on MMC using DD     You can also use dd on any linux system to load redboot:   $ sudo dd if=./Desktop/mx35_3stack_redboot_mmc.bin of=/dev/sdd bs=512 skip=2 seek=2 Configuring Kernel to Boot From SD/MMC     Creating a Linux bootable MMC/SD Card.     Execute LTIB:   $ ./ltib -c     Choose configure the kernel:   [*] Configure the kernel     Change image generation to NFS:     Target Image Generation     Options --->     (X) NFS only     Compile Linux kernel with built-in support to MMC/SD and ext3:     Follow that sequence:     Device Drivers --->     <*> MMC/SD card support --->     <*> UniFi SDIO glue for Freescale MMC/SDIO     <*> Freescale i.MX Secure Digital Host Controller Interface support       File systems --->     <*> Ext3 journalling file system support     After the compilation copy the file ~/ltib/rootfs/boot/zImage to tftpboot directory:   $ cp ~/ltib/rootfs/boot/zImage /tftpboot Creating RedBoot Kernel Partition     Create RedBoot partitions and copy Linux kernel to it:     Turn MMC active:   RedBoot> factive MMC     Initialize flash partitions:   RedBoot> fis init       RedBoot> fis list     ... Read from 0x07ee0000-0x07eff000 at 0x00060000: .     Name FLASH addr Mem addr Length Entry point     RedBoot 0x00000000 0x00000000 0x00040000 0x00000000     FIS directory 0x00060000 0x00060000 0x0001F000 0x00000000     RedBoot config 0x0007F000 0x0007F000 0x00001000 0x00000000     Load kernel to RAM:   RedBoot> load -r -b 0x100000 /tftpboot/zImage     Using default protocol (TFTP)     Raw file loaded 0x00100000-0x002c31b7, assumed entry at 0x00100000     Create a kernel partition with content of kernel image loaded to RAM:       RedBoot> fis create -f 0x200000 kernel         RedBoot> fis list     ... Read from 0x07ee0000-0x07eff000 at 0x00060000: .     Name FLASH addr Mem addr Length Entry point     RedBoot 0x00000000 0x00000000 0x00040000 0x00000000     FIS directory 0x00060000 0x00060000 0x0001F000 0x00000000     RedBoot config 0x0007F000 0x0007F000 0x00001000 0x00000000     kernel 0x00200000 0x00100000 0x001E0000 0x00100000     If you reset your board you need to see:   Booting from [SD card, CSD Version 1.0]     If instead you see this message:   Booting from [unknown version card ]     This means your card is not support, please replace it with other card. Creating the Root File System     After storing the kernel image in the SD card, remove the card from the target board and insert it in your computer (running Linux).     In this example, Linux detected the SD card as /dev/sdb.     Now we need to create two partitions. The first partition will not be used, this is just reserved to RedBoot and kernel. The second partition will be used to store Linux Root File System.   # fdisk /dev/sdb     Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel     Building a new DOS disklabel with disk identifier 0x526c22da.     Changes will remain in memory only, until you decide to write them.     After that, of course, the previous content won't be recoverable.         Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)         Command (m for help): p         Disk /dev/sdb: 1023 MB, 1023934464 bytes     32 heads, 62 sectors/track, 1008 cylinders     Units = cylinders of 1984 * 512 = 1015808 bytes     Disk identifier: 0x526c22da           Device Boot Start End Blocks Id System     Create the first partition with 8 MB; it already contains RedBoot and the kernel, as we stored previously:             Command (m for help): n     Command action       e extended       p primary partition (1-4)     p     Partition number (1-4): 1     First cylinder (1-1008, default 1):     Using default value 1     Last cylinder, +cylinders or +size{K,M,G} (1-1008, default 1008): +8M     Now, create the second partition using all remaining space on SD card:       Command (m for help): n     Command action       e extended       p primary partition (1-4)     p     Partition number (1-4): 2     First cylinder (10-1008, default 10):     Using default value 10     Last cylinder, +cylinders or +size{K,M,G} (10-1008, default 1008):     Using default value 1008         Command (m for help): p         Disk /dev/sdb: 1023 MB, 1023934464 bytes     32 heads, 62 sectors/track, 1008 cylinders     Units = cylinders of 1984 * 512 = 1015808 bytes     Disk identifier: 0x526c22da     Device Boot Start End Blocks Id System     /dev/sdb1 1 9 8897 83 Linux     /dev/sdb2 10 1008 991008 83 Linux         Command (m for help): w   Now format the second partition as EXT3: # mkfs.ext3 /dev/sdb2   Remove the SD card from your computer and insert again. Probably your Linux distribution will dectect it and will mount automatically.   On Ubuntu 8.10 it was mounted on /dev/media:   # mount   ...   /dev/sdb2 on /media/disk type ext3 (rw,nosuid,nodev,uhelper=hal) If your Linux didn't mount it, then you can mount it manually:   # mkdir -p /media/disk   # mount /dev/sdb2 -t ext3 /media/disk   Enter in your LTIB directory and copy the rootfs content to SD card:   # cd /home/alan/ltib-imx35/rootfs/   # cp -a * /media/disk/   Verify if it was copied correctly:   # ls -l /media/disk/   total 80   drwxr-xr-x 2 root root 4096 2009-03-12 09:55 bin   drwxr-xr-x 2 root root 4096 2009-03-12 09:53 boot   drwxr-xr-x 2 root root 4096 2009-03-12 09:55 dev   drwxr-xr-x 6 root root 4096 2009-03-12 14:41 etc   drwxr-xr-x 3 root root 4096 2009-03-12 09:53 home   drwxr-xr-x 4 root root 4096 2009-03-12 09:55 lib   lrwxrwxrwx 1 root root 11 2009-03-12 14:47 linuxrc -> bin/busybox   drwx------ 2 root root 16384 2009-03-12 14:37 lost+found   drwxr-xr-x 7 root root 4096 2009-03-12 09:53 mnt   drwxr-xr-x 2 root root 4096 2009-03-12 09:53 opt   drwxr-xr-x 2 root root 4096 2009-03-12 09:53 proc   drwxr-xr-x 2 root root 4096 2009-03-12 10:10 root   drwxr-xr-x 2 root root 4096 2009-03-12 09:55 sbin   drwxr-xr-x 2 root root 4096 2009-03-12 09:53 sys   drwxrwxrwt 3 root root 4096 2009-03-12 09:53 tmp   drwxr-xr-x 2 root root 4096 2009-03-12 09:55 unit_tests   drwxr-xr-x 9 root root 4096 2009-03-12 09:55 usr   drwxr-xr-x 11 root root 4096 2009-03-12 09:55 var   root@urubu:~/ltib-imx25/rootfs#     Now umount the SD card:   # umount /media/disk Configuring RedBoot to Load Kernel and Rootfs from SD/MMC Card     Remove the SD card from your computer and place again in the board.     Configure RedBoot to load the kernel from SD/MMC card and set up the kernel command parameter "root" to load the root file system from second SD/MMC card partition (/dev/mmcblk0p2)     RedBoot> fc     Run script at boot: true     Boot script:     Enter script, terminate with empty line     >> fis load kernel     >> exec -b 0x100000 -l 0x200000 -c "noinitrd console=ttymxc0,115200 root=/dev/mmcblk0p2 init=/linuxrc ip=none"     >>     Boot script timeout (1000ms resolution): 1     Use BOOTP for network configuration: false     Gateway IP address: 10.29.244.254     Local IP address: 10.29.244.135     Local IP address mask: 255.255.0.0     Default server IP address: 10.29.240.182     Board specifics: 0     Console baud rate: 115200     Set eth0 network hardware address [MAC]: false     Set FEC network hardware address [MAC]: false     GDB connection port: 9000     Force console for special debug messages: false     Network debug at boot time: false     Default network device: lan92xx_eth0     Update RedBoot non-volatile configuration - continue (y/n)? y     ... Read from 0x07ee0000-0x07eff000 at 0x00060000: .     ... Erase from 0x00060000-0x00080000: .     ... Program from 0x07ee0000-0x07f00000 at 0x00060000: .       Now just reset the board and it will boot directly from SD/MMC card.

The new i.MX OTP Tools release is now available on http://www.freescale.com/, under this link. Change details: Fixes an issue with the rom-plugin device firmware that is used by BitBurner and otp_burner tools to program fuses. These tools are part of IMX_OTP_TOOLS package.    The plugin was failing to check the status whether the data packets have been received or not.    As such, at times before receiving data from host the firmware was processing the usb buffer    with previously sent or received data resulting in incorrect values being programmed. To fix    this issue we modified the firmware to make sure we receive the data before processing the usb buffer.                 Here is the sequence of usb transfers (protocol):                 1.            Cmd-phase: Host send cmd to write to otp register with cmd type, register index and number of registers to write                 2.            Data-phase: Host send data for values to write to otp register.                 3.            Status-phase: Device sends status to host                 4.            Cmd-phase: Host send cmd to read otp register to verify data written was correct                 5.            Data-phase: Device send data from otp registers                 6.            Status-phase: Device sends status to host   The problem was at #2 wherein device would process usb buffer before confirming whether data has received or not.

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

This is a workaround—this page needs to be updated to add instructions for multi-touch support. Based on Freescale BSP 11.05. The LVDS panel (MCIMX-LVDS1) has a serial multi-touch controller, eGalax. As a workaround to have it supported on directly on Qt, we can force the driver to behave as a single touch. To do this: 1 - Edit the file ltib/rpm/BUILD/linux-2.6.35.3/drivers/input/touchscreen/egalax_ts.c adding the following line: + #define FORCE_SINGLE_POINTER_SUPPORT 1 2 - Compile the kernel ./ltib -m scbuild -p kernel 3 - Copy the new kernel to Card/Memory and boot it. 4 - Start your Qt app: $ Xfbdev -screen 1024x768 -mouse tslib,,device=/dev/input/event0  & $ export DISPLAY=:0.0 $ ./yourQTapp Note: You can read the touch events with "evtest" $ evtest  /dev/input/event0 or tslib apps: $ export TSLIB_TSDEVICE=/dev/input/event0 $ ts_print

This is the procedure and patch to set up Ubuntu 12.04 64bit Linux Host PC and building i.MX28 L2.6.35_1.1.0_130130.  It has been tested to build GNOME profile and with FSL Standard MM codec. A) Basic Requirement: Set up the Linux Host PC using ubuntu-12.04.3-desktop-amd64.iso Make sure the previous LTIB installation and the /opt/freescale have been removed B) Installed the needed packages to the Linux Host PC $ sudo apt-get update $ sudo apt-get install gettext libgtk2.0-dev rpm bison m4 libfreetype6-dev $ sudo apt-get install libdbus-glib-1-dev liborbit2-dev intltool $ sudo apt-get install ccache ncurses-dev zlib1g zlib1g-dev gcc g++ libtool $ sudo apt-get install uuid-dev liblzo2-dev $ sudo apt-get install tcl dpkg $ sudo apt-get install asciidoc texlive-latex-base dblatex xutils-dev $ sudo apt-get install texlive texinfo $ sudo apt-get install ia32-libs libc6-dev-i386 lib32z1 $ sudo apt-get install uboot-mkimage $ sudo apt-get install scrollkeeper $ sudo apt-get install gparted $ sudo apt-get install nfs-common nfs-kernel-server $ sudo apt-get install git-core git-doc git-email git-gui gitk $ sudo apt-get install meld atftpd C) Unpack and install the LTIB source package and assume done on the home directory: $ cd ~ $ tar -zxvf L2.6.35_1.1.0_130130_source.tar.gz $ ./L2.6.35_1.1.0_130130_source/install After that, you will find ~/ltib directory created D) Apply the patch to make L2.6.35_1.1.0 could be installed and compiled on Ubuntu 12.04 64bit OS $ cd ~/ltib $ git apply 0001_make_L2.6.35_1.1.0_130130_compile_on_ubuntu_12.04_64bit_OS.patch a) The patch modifies the following files:    dist/lfs-5.1/base_libs/base_libs.spec    dist/lfs-5.1/lkc/lkc.spec    dist/lfs-5.1/mux_server/mux_server.spec    dist/lfs-5.1/ncurses/ncurses.spec b) Add the following files to the pkgs directory:    pkgs/lkc-1.4-lib.patch    pkgs/lkc-1.4-lib.patch.md5 E) Then, it is ready to proceed the rest of the LTIB env setup process: $ cd ~/ltib $ ./ltib -m config $ ./ltib Reference: L2.6.35_1.1.0_130130_docs/doc/mx28/Setting_Up_LTIB_Host_on_Ubuntu_9_04.pdf https://community.freescale.com/docs/DOC-93394 https://community.freescale.com/message/332385#332385 https://community.freescale.com/thread/271675 https://community.freescale.com/message/360556#360556 scrollkeeper is for the gnome-desktop compilation NOTE: When compiling gstreamer, this warning was pop up.  Just ignore it seems okay.

Platform: i.MX8MP EVK, SDK 2.16   The rpmsg debug will stuck at rpmsg_queue_recv/rpmsg_lite_send when we use Step Over debug with JLink. The error log on Linux side: [ 42.422658] remoteproc remoteproc0: kicking vq index: 1 [ 42.524256] imx-rproc imx8mp-cm7: imx_rproc_kick: failed (1, err:-62) [ 42.524286] remoteproc remoteproc0: kicking vq index: 0 [ 42.628566] imx-rproc imx8mp-cm7: imx_rproc_kick: failed (0, err:-62)   The demo source code of rpmsg in SDK uses  RL_BLOCK, this flag will cause communication stuck during debug. while (msg.DATA <= 100U) { (void)PRINTF("Waiting for ping...\r\n"); (void)rpmsg_queue_recv(my_rpmsg, my_queue, (uint32_t *)&remote_addr, (char *)&msg, sizeof(THE_MESSAGE), ((void *)0), RL_BLOCK); msg.DATA++; (void)PRINTF("Sending pong...\r\n"); (void)rpmsg_lite_send(my_rpmsg, my_ept, remote_addr, (char *)&msg, sizeof(THE_MESSAGE), RL_BLOCK); }   The solution for rpmsg step over debug is that we need to use RL_DONT_BLOCK in sdk.    

[中文翻译版] 见附件   原文链接： https://community.nxp.com/docs/DOC-342719 

the enclosed code is based on How to fuse key through nvmem on i.MX93 - NXP Community and modified for the imx8mp, this article about how to fuse mac address via fuse command in the uboot or nvmem in the kernel  ================================================================ Any support, information, and technology (“Materials”) provided by NXP are provided AS IS, without any warranty express or implied, and NXP disclaims all direct and indirect liability and damages in connection with the Material to the maximum extent permitted by the applicable law. NXP accepts no liability for any assistance with applications or product design.  Materials may only be used in connection with NXP products. Any feedback provided to NXP regarding the Materials may be used by NXP without restriction.

This guide provides a step-by-step approach for beginners looking to flash a custom Kernel Image or device tree on an NXP i.MX board. Sometimes, we need to customize the Kernel Image or modify the device tree for our board. Fortunately, NXP provides the UUU (Universal Update Utility) tool, which allows us to flash and use a custom Kernel Image or update the device tree on our board.   Requirements Before proceeding, ensure you have the following: - The latest version of the UUU Tool. - An i.MX EVK board (i.MX6, i.MX7, i.MX8, i.MX9). - The power supply for the board. - Two USB cables (USB-C or Micro USB, depending on your board).   Preliminary Steps To customize the Kernel Image or device tree, refer to the following community posts: - How to Fix FRDM-IMX93 Linux Kernel BSP - How to Compile Linux Kernel Image and Device Tree Using Yocto SDK   Once you have your customized Linux Kernel Image or device tree ready, follow the steps below to deploy it to your board.   Flashing the Kernel Image or Device Tree Connect and Prepare the Board 1. Connect the USB debug cable and the OTG cable from your board to your host computer. 2. Power on your board and stop the boot process at the U-Boot stage by pressing a key in the terminal. 3. Enter fastboot mode by running the following command in the U-Boot terminal: u-boot -> fastboot 0   Flash the Custom Kernel Image or Device Tree   4. Open a terminal on your host computer and navigate to the directory containing the new Kernel Image or device tree. 5. Flash the new files using the following command: $ uuu -b fat_write <file_name> mmc <device>:<partition> <file_name_in_board> Example: $ uuu -b fat_write imx93-11x11-evk.dtb mmc 0:1 imx93-11x11-evk-custom.dtb In this example, the file imx93-11x11-evk.dtb stored on the host machine is flashed to the board's eMMC device, saving it as imx93-11x11-evk-custom.dtb.   Note: If you are using Linux, run the command with sudo. - For eMMC and SD card, the command is the same; just ensure you use the correct device number. - On the i.MX93, device 0 corresponds to eMMC, and device 1 corresponds to the SD card.   Update U-Boot Environment Variables   6. Exit fastboot mode by pressing CTRL+C. This returns you to the U-Boot terminal. 7. Set up the environment variablesto use the new files: For the Kernel Image: u-boot -> setenv image <custom_image_name> u-boot -> saveenv u-boot -> reset For the Device Tree: u-boot -> setenv fdtfile <custom_device_tree_name> u-boot -> saveenv u-boot -> reset The board should now boot using your modified Kernel Image and device tree.  

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.

i.MX93 eMMC Secondary Boot          i.MX93 eMMC Secondary Boot.zip   i.MX8MP eMMC Secondary Boot           i.MX8MP eMMC Secondary Boot.zip i.MX8MM SDCARD Secondary Boot Demo https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/i-MX8MM-SDCARD-Secondary-Boot-Demo/ta-p/1500011   i.MX8QXP eMMC Secondary Boot https://community.nxp.com/t5/i-MX-Community-Articles/i-MX8QXP-eMMC-Secondary-Boot/ba-p/1257704#M45    i.MX6 SDCARD Secondary Boot Demo           i.MX6_SDCARD_Secondary_Boot_Demo.pdf      

Hello, here Jorge. On this post I will explain how to enable MQS1 on i.MX8ULP. As background about how to setup the environment to build the image using Yocto, please take a look on our i.MX Yocto Project User's Guide: Requirements: i.MX 8ULP EVK. Serial console emulator (Tera Term, Putty, etc.). USB Type-C cable. Micro USB cable. Headphones/speakers. Linux PC. Build done in Linux 6.6.23_2.0.0. i.MX8ULP audio subsystem. i.MX 8ULP extends audio capabilities on i.MX 7ULP by adding dedicated DSP cores for voice trigger and audio processing, enabling lower latency and power efficiency to support variety of audio applications. Some of hardware blocks implemented on 8ULP to support audio use cases are the next: Cadence Fusion F1 DSP processor. Cadence HiFi4 DSP processor. PowerQuad hardware accelerator with fixed and floating + FFT. Digital Microphone interface with support of up-to 8 PDM channels. Up-to 8 independent SAI instances. Up-to 2 Medium Quality Sound (MQS). Sony/Philips Digital interface (SPDIF). As is described before, MQS0 and MQS1 are part of real time domain and application domain respectively. I’m going to focus this post on how to enable MQS1 on application domain. Medium Quality Sound (MQS)  This module is basically generates a PWM from PCM audio data. For the major part of typical audio applications will require an external CODEC to deliver the audio quality but, sometimes where the application does not demand this quality, MQS can provide a medium quality audio via GPIO pin that can directly drive the audio output to a speaker or headphone via inexpensive external amplifier/buffer instead of CODEC. The design of the MQS can be described as follows: Input the PCM audio data (from SAI) into a 16-bit register. Up-sample data to match PWM switching frequency. Perform a simple 2nd order Sigma-Delta smooth on the current data versus previous data. Convert the PCM register into a 6-bit PWM width register and output through a GPIO pin.   How to enable it? By default, our BSP does not enable clock for MQS1. This clock is controlled on CGC1 (AD), specifically on MQS1CLK (Multiplexer to select the audio clock connected to the MQS clock input). So, it is needed to modify imx8ulp-clock.h and clk-imx8ulp.c. Please take a look on patch attached at the end of this post to see the modification in drivers easily. These drivers have the definition/configuration for MQS1_SEL in CGC1 and needs to be added as follows: MQS1_SEL definition needs to be added in imx8ulp-clock.h: #define IMX8ULP_CLK_MQS1_SEL 56 #define IMX8ULP_CLK_CGC1_END 57 MQS1_SEL configuration needs to be added in imx8ulp_clk_cgc1_init of clk-imx8ulp.c: clks[IMX8ULP_CLK_MQS1_SEL] = imx_clk_hw_mux2("mqs1_sel", base + 0x90c, 0, 2, sai45_sels, ARRAY_SIZE(sai45_sels)); Also, it is necessary to configure MQS1 on device tree of i.MX8ULP. Add this in soc: soc@0 of imx8ulp.dtsi: mqs1: mqs@0x29290064 { reg = <0x29290064 0x4>; compatible = "fsl,imx8qm-mqs"; assigned-clocks = <&cgc1 IMX8ULP_CLK_MQS1_SEL>; assigned-clock-parents = <&cgc1 IMX8ULP_CLK_SPLL3_PFD1_DIV1>; clocks = <&cgc1 IMX8ULP_CLK_MQS1_SEL>, <&cgc1 IMX8ULP_CLK_MQS1_SEL>; clock-names = "core", "mclk"; status = "disabled"; }; And create a new device tree, in this case is going to be named imx8ulp-evk-mqs.dts and is as follows: #include "imx8ulp-evk.dts" / { sound-simple-mqs { compatible = "simple-audio-card"; simple-audio-card,name = "imx-simple-mqs"; simple-audio-card,frame-master = <&sndcpu>; simple-audio-card,bitclock-master = <&sndcpu>; simple-audio-card,dai-link@0 { format = "left_j"; sndcpu: cpu { sound-dai = <&sai4>; }; codec { sound-dai = <&mqs1>; }; }; }; }; &cgc1 { assigned-clock-rates = <24576000>; }; &iomuxc1 { pinctrl_mqs1: mqs1grp { fsl,pins = < MX8ULP_PAD_PTF7__MQS1_LEFT 0x43 >; }; }; &mqs1 { #sound-dai-cells = <0>; pinctrl-names = "default"; pinctrl-0 = <&pinctrl_mqs1>; status = "okay"; }; &sai4 { #sound-dai-cells = <0>; assigned-clocks = <&cgc1 IMX8ULP_CLK_SAI4_SEL>; assigned-clock-parents = <&cgc1 IMX8ULP_CLK_SPLL3_PFD1_DIV1>; status = "okay"; }; Let’s apply these changes on our BSP, in my case I’m going to create a new layer in Yocto to add these modifications with a patch that can be found at the end on this post, here the steps: Install essential Yocto Project host packages: $ sudo apt install gawk wget git diffstat unzip texinfo gcc build-essential chrpath socat cpio python3 python3-pip python3-pexpect xz-utils debianutils iputils-ping python3-git python3-jinja2 python3-subunit zstd liblz4-tool file locales libacl1 Install the “repo” utility: $ mkdir ~/bin $ curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo $ chmod a+x ~/bin/repo $ export PATH=~/bin:$PATH Set up Git: $ git config --global user.name "Your Name" $ git config --global user.email "Your Email" $ git config –list Download the i.MX Yocto Project Community BSP recipe layers and create build folder: $ mkdir imx-yocto-bsp $ cd imx-yocto-bsp $ repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-scarthgap -m imx-6.6.23-2.0.0.xml $ repo sync $ DISTRO=fsl-imx-wayland MACHINE=imx8ulp-lpddr4-evk source imx-setup-release.sh -b 8ulp_build Create the new layer: $ cd ~/imx-yocto-bsp/sources $ bibake-layers create-layer meta-mqs $ cd meta-mqs conf/layer.conf should be as follows: BBPATH .= ":${LAYERDIR}" BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \ ${LAYERDIR}/recipes-*/*/*.bbappend" BBFILE_COLLECTIONS += "meta-mqs" BBFILE_PATTERN_meta-mqs = "^${LAYERDIR}/" BBFILE_PRIORITY_meta-mqs = "6" LAYERSERIES_COMPAT_meta-mqs = "nanbield" Let’s change the recipe: $ sudo rm -r recipes-example $ mkdir -p recipes-kernel/linux/files 0001-8ULP-MQS-Enable.patch should be copied to ~/imx-yocto-bsp/sources/meta-mqs/recipes-kernel/linux/files Add an append (on this case is called “linux-imx_%.bbappend”)to change the recipe with next content: FILESEXTRAPATHS:prepend := "${THISDIR}/files:" SRC_URI += "file:// 0001-8ULP-MQS-Enable.patch " addtask copy_dts after do_unpack before do_prepare_recipe_sysroot do_copy_dts () { if [ -n "${DTS_FILE}" ]; then if [ -f ${DTS_FILE} ]; then echo "do_copy_dts: copying ${DTS_FILE} in ${S}/arch/arm64/boot/dts/freescale" cp ${DTS_FILE} ${S}/arch/arm64/boot/dts/freescale/ fi fi } The next step is add the layer and build the image: $ cd ~/imx-yocto-bsp/8ulp_build $ bitbake-layers add-layer ~/imx-yocto-bsp/sources/meta-mqs Confirm that the layer has been added: $ bitbake-layers show-layers Build the image: $ bitbake imx-image-multimedia i.MX8ULP EVK limitations The i.MX8ULP has the next MQS1 pins available: But, in the EVK board, the mayor part of these pins are used for other functions such as: - Push button: - MIPI DSI:  - Etc… So, take the output signal of MQS1 pins of EVK board is difficult, in this article, I’m going to configure PTF7 only (MQS1_left) for practicality. If you are working with this board and you need to use these pins for MQS function you will need to manipulate the traces and take the required signals. If you are designing a custom board, planning is essential to avoid this issue. Flash the board. One the build has been finished, we will have the necessary files to flash the board and test it. If you are not too familiarized with this process I suggest you take a look on this post. First, put the board in serial download mode changing the boot configuration switches on the board:   The next step is connecting the power cable, micro-USB cable on the debug port and USB-C type cable to USB0 connector on the board. Then, turn-on the board and run the next command in terminal of build directory: uuu -b emmc_all imx-boot-imx8ulpevk-sd.bin-flash_singleboot_m33 imx-image-multimedia-imx8ulpevk.wic Now, power-off the board, change the boot mode to single boot-eMMC and power it on to test it. Test MQS1 in i.MX8ULP. To test MQS1 it is needed to change the device tree we created, we can do it with the next commands in U-boot: u-boot=> setenv fdtfile imx8ulp-evk-mqs.dtb u-boot=> saveenv u-boot=> boot Now we can test MQS1 on i.MX8ULP EVK, let's confirm that the clock is active in MQS module with the next command: $ cat /sys/kernel/debug/clk/clk_summary -n As you can see mqs1_sel is active and running at 24576000 Hz: And the card appears if we run the next command: $ aplay -l To play audio through MQS we can do it as any sound card: $ speaker-test -D sysdefault:CARD=imxsimplemqs -c 2 -f 48000 -F S16_LE -t pink -P 3 The signal should look like this in the pin output: And like this after a filter, for example the filter used in i.MX93 EVK.   With this post we have been able check the general operation of MQS, configure and compile the image with the required changes to enable MQS1 on EVK board and measure the output on the board. There is a considerable limitation on EVK board since we cannot test left and right outputs without intervene the base board, but this can be helpful as a reference to who would like to use this audio output on i.MX8ULP processor. Best regards. References. Yocto Project customization guide - NXP Community How to add a new layer and a new recipe in Yocto - NXP Community Flashing Linux BSP using UUU - NXP.  i.MX8ULP reference manual. Embedded Linux Projects Using Yocto Project Cookbook.

Hello! In this time, we will look how the i.MX93 GPIOs IRQs works, also I will focus on Cortex M33 side with SDK 2_16_0 but also tested on 2_15.   We can see in this other post, how the i.MX8M family works, but for i.MX93 this is a little different because there are a Secure/Non-Secure options and Privilege/Non-Privilege.   According to reference Manual and SDK LED example, we must to set the PCNS and ICNS registers to 0x00 to set in Secure access.    Materials Used: i.MX93EVK Jumper cable to connect GPIO2_IO02 with GPIO2_IO03 SDK 2_16_0 from MCUXpresso SDK Builder Source power for i.MX93EVK USB C Cable for serial debug USB C Cable to transfer .bin ro EVK   The Cortex-M33 processor supports Secure and Non-secure security states, Thread and Handler operating modes, and can run in either Thumb or Debug operating states. In addition, the processor can limit or exclude access to some resources by executing code in privileged or unprivileged mode. Code can execute as privileged or unprivileged. Unprivileged execution limits or excludes access to some resources appropriate to the current security state. Privileged execution has access to all resources available to the security state. Handler mode is always privileged. Thread mode can be privileged or unprivileged. You can find this information in the ARM documentation.   To resume this post, we will focus just in the necessary registers to configure properly a GPIO as IRQ input.   On this example, we will take the i.MX93EVK board. The GPIO2_IO02 will be configured as an output and the GPIO2_IO03 will be configured as an input with Rising edge IRQ. On each GPIO2_IO02 Rising edge, the software will detect an IRQ.     At first, we need to configure our IOMUX: void BOARD_InitPins(void) { IOMUXC_SetPinMux(IOMUXC_PAD_GPIO_IO02__GPIO2_IO02, 0U); IOMUXC_SetPinMux(IOMUXC_PAD_GPIO_IO03__GPIO2_IO03, 0U); IOMUXC_SetPinMux(IOMUXC_PAD_UART2_RXD__LPUART2_RX, 0U); IOMUXC_SetPinMux(IOMUXC_PAD_UART2_TXD__LPUART2_TX, 0U); IOMUXC_SetPinConfig(IOMUXC_PAD_GPIO_IO02__GPIO2_IO02, IOMUXC_PAD_DSE(15U) | IOMUXC_PAD_FSEL1(2U) | IOMUXC_PAD_PD_MASK); IOMUXC_SetPinConfig(IOMUXC_PAD_GPIO_IO03__GPIO2_IO03, IOMUXC_PAD_PD_MASK); IOMUXC_SetPinConfig(IOMUXC_PAD_UART2_RXD__LPUART2_RX, IOMUXC_PAD_PD_MASK); IOMUXC_SetPinConfig(IOMUXC_PAD_UART2_TXD__LPUART2_TX, IOMUXC_PAD_DSE(15U)); }   Then, we can start to code. Using as an starting point we can use the SDK/boards/mcimx93evk/driver_examples/rgpio/led_output example. Our definitions (PIN_OUT_RGPIO and PIN_IN_RGPIO are the same GPIO2 but it is just for good practice):😞 /******************************************************************************* * Definitions ******************************************************************************/ #define PIN_OUT_RGPIO GPIO2 #define PIN_IN_RGPIO GPIO2 #define PIN_OUT_RGPIO_PIN 2U #define PIN_IN_RGPIO_PIN 3U   Then, our IRQ handler: void Reserved73_IRQHandler(void) { RGPIO_ClearPinsInterruptFlags(PIN_IN_RGPIO, kRGPIO_InterruptOutput0, 1U << PIN_IN_RGPIO_PIN); PRINTF("\r\n IRQ.........\r\n"); SDK_ISR_EXIT_BARRIER; }   Why Reserved73_IRQHandler? That is the correspondent for GPIO2, you can look this on SDK/devices/MIMX9352/gcc in the file called startup_MIMX9352_cm33.S:   Basically, the interruption will clear the IRQ flag and print a little message.   Now, here we have the complete main function, we will break down the most important points. int main(void) { /* Define the init structure for the output pin*/ rgpio_pin_config_t pin_out_config = { kRGPIO_DigitalOutput, 0, }; rgpio_pin_config_t pin_in_config = { kRGPIO_DigitalInput, 0, }; /* Board pin, clock, debug console init */ /* clang-format off */ const clock_root_config_t rgpioClkCfg = { .clockOff = false, .mux = 0, // 24Mhz Mcore root buswake clock .div = 1 }; /* clang-format on */ BOARD_InitBootPins(); BOARD_BootClockRUN(); BOARD_InitDebugConsole(); CLOCK_SetRootClock(EXAMPLE_RGPIO_CLOCK_ROOT, &rgpioClkCfg); CLOCK_EnableClock(EXAMPLE_RGPIO_CLOCK_GATE); CLOCK_EnableClock(kCLOCK_Gpio2); /* Set PCNS register value to 0x0 to prepare the RGPIO initialization */ PIN_OUT_RGPIO->PCNS = 0x0; PIN_IN_RGPIO->ICNS = 0x0; /* Print a note to terminal. */ PRINTF("\r\n RGPIO Driver example\r\n"); PRINTF("\r\n An IRQ will happen each GPIO2_IO02 Rising edge\r\n"); /* Init output PIN GPIO. */ RGPIO_PinInit(PIN_OUT_RGPIO, PIN_OUT_RGPIO_PIN, &pin_out_config); /* Init Input with IRQ Pin GPIO*/ RGPIO_SetPinInterruptConfig(PIN_IN_RGPIO, PIN_IN_RGPIO_PIN, kRGPIO_InterruptOutput0, kRGPIO_InterruptRisingEdge); EnableIRQ(GPIO2_0_IRQn); RGPIO_PinInit(PIN_IN_RGPIO, PIN_IN_RGPIO_PIN, &pin_in_config); while (1) { SDK_DelayAtLeastUs(1000000U, SystemCoreClock); RGPIO_PortToggle(PIN_OUT_RGPIO, 1u << PIN_OUT_RGPIO_PIN); } }   As we can see, we need set the GPIO2 PCNS register to 0x00:   Pin Control Nonsecure (PCNS) Configures secure or nonsecure access protection for each pin. You can write to this register only in the Secure-Privilege state if it is not locked (LOCK[PCNS] = 0).   Also the ICNS register to 0x00.   Interrupt Control Nonsecure (ICNS) Configures secure and nonsecure access protection for each interrupt, or DMA request. You can update this register only in the Secure-Privilege state if it is not locked (LOCK[ICNS] = 0).   Now, we can compile and run the example. On each GPIO2_IO02 Rising edge, the CM33 will detect an IRQ in GPIO2_IO03 (short those pads as showed in the image at first of the post).     I will attach the full .c file.   I hope this information can helps to everyone.   Best regards, --... ...-- Salas.

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.