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.    

Why SWPDM? i.MX8MMINI, i.MX8MNANO and IMX8MPLUS  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   Data Flow   When using PDM Microphones the default data flows is as shown in figure 1. Where the data is capture in the MICFIL peripheral and when it get to the Sound Drivers the data is already converted to PCM, so from the Kernel perspective the data is treaty as PCM values and the conversion from PDM to PCM is done under the hardware. However, with the changes we made earlier on the device tree and adding the plugin on /etc/asound.conf the data flows is as follow: Where the conversion from PDM to PCM is done just before giving the buffer to the application layer; Thus, conversion is made on User Space and the kernel is aware data have a PDM format. Another difference you can see is that MICFIL is disable and instead the datalines are controlled by SAI5. This is true for i.MX8MM, i.MX8MN, and i.MX8MP. Although for the application is a transparent change the truth is that the entire pipeline change, so please be aware of how the data is flowing to your application.   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 mic 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. 

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  

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.

i.MX8M_DDR3L_register_programming_aid is created for DDR3L validation board.

When using SSI Slave Mode for ASRC_P2P function (https://community.freescale.com/docs/DOC-95342), the waveform of the converted 24bit data is abnormal(have some values between 0 and 1). When using SSI Master Mode, these abnormal data disappear. This patch shows how to enable SSI Master Mode based on ASRC_P2P patches. Because SSI Master Mode uses fixed data width for LRCLK(32bits for each L or R), and the SSI Dual FIFO Mode is not supported for ASRC_P2P, the converted 16bit data is not well supported in this patch. Suggestions: If you want to convert the audio data to 16bit, you can use SSI Slave Mode; if you want to convert the audio data to 24bit, you can use SSI Master Mode.

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.

Based on example code provided in AN4466 I've written a simple memory calibration script for ARM DS-5 that runs same steps and prints out results for DQS, read and write calibration. This script can be run on new boards in order to find optimum calibration settings for the memory controller. Prior to running this script it is necessary to run standard memory initialization script! When bringing up new board: obtain default memory initialization script for memory type you're using (for example from DDR stress tester package) and modify the memory controller settings according to memory device you are going to use. run DDR stress tester with the given configuration on target frequency you're going to use to make memory works with given settings (default values for calibration are  fine in most cases unless there's issues with PCB and/or routing). run memory init script and then the attached script to obtain calibrated values. Re-test Vladan

The patches are based on iMX53 L2.6.35_ER1109 BSP. In default linux BSP, the followed two pathes were supported in kernel driver mxc_v4l2_capture.c: CSI->IC->MEM CSI->MEM After appied these two patches, it can support the followed path: CSI->VDI->IC->MEM In this mode, the VDI de-interlace will be handled on the fly, so the whole system bandwidth will be reduced. Limitations: 1. Since the IC can only output resolution up to 1024*1024, so this is the limation on output. 2. Only VDI motion mode 2 was supported. mxc_v4l2_tvin_vdi_ic.zip: It is the test aplication, test command: "./mxc_v4l2_tvin.out -ol 0 -ot 0 -ow 800 -oh 480 -i 2" "-i 2" means CSI->VDI->IC->MEM path.

NOTE: Always de-power the target board and the aggregator when plugging or unplugging smart sensors from the aggregator. The aggregator portion of the i.MX Power Profiling System sits between the "smart" current sensor boards and the host computer. It provides power and signal connections to each connected sensor board. The communication is done over I2C, where three I2C bus extenders (PCA9518) effectively provide a dedicated bus to each I2C device, to better allow for cabling.  More information will follow... A photo, layout images and schematic attached below.   MBED source for the FRDM-KL25Z is available here: 30848-KL25Z-AGGREGATOR    Smart Sensor Connections At each smart sensor header JP0-JP13, these are the connections provided: 5V: powers the 3.3V regulator on each sensor board 12V: all the gates of all the switching FETs are pulled pulled up to 12V GND: ground connection SCL/TX0: I2C clock line  SDA/RX0: I2C data line  SWD_CLK:  global line for triggering smart sensors to make measurements RESET_B:  global line for resetting all smart sensor boards SWD_IO_n: individual select line for each smart sensor I2C Bus Connection Three I2C bus extenders (PCA9518) provide buffered connections between the FRDM board and all the connected smart sensors. The bus extenders were added to allow for longer cables between the aggregator and the smart sensor boards. Each bus extender has five ports and along with connections that allow extending the bus to more bus extenders. Gate Supply The aggregator contains a boost regulator that boost the 5V input from the FRDM board to 12V. The boosted voltage is fed to each of the smart sensor headers. It's used by the smart sensor board to pull up the gates of the switching FETs above any of the rails under test by at least 4.5V in order to benefit from a lower Rds(on). Caution must be exercised with some older FRDM boards since the 5V from the USB connection passes through diodes with a maximum current of 200mA.  The boost regulator and the load presented by the smart sensor boards may exceed the diode's limit and damage it. (Yes, it's happened... two older FRDM-KL25Z boards were used during development. One of them failed with the diode shorted (~0.05 Ohms), so everything kept working. The other failed with a  short of ~45 Ohms, so it kind of worked but not really...) Application Code for Aggregator  To date, application code has only been developed for the FRDM-KL25Z board. The latest application code resides at: https://os.mbed.com/users/r14793/code/30848-KL25Z-AGGREGATOR/, with the latest binary attached below. SWD Programming of Smart Sensors  Connectors J5 and JP15 are provided as an adapter for programming the smart sensor boards via SWD. JP15 provides power to the smart sensor board, since they have no direct 3.3V input for the KL05Z. An SWD programmer (or suitably modified FRDM-KL05Z board) connects to J5. Both connections use 10-pin 0.05"-spaced ribbon cables. Additionally, when a smart sensor is connected to JP15, J6 provides access to the UART pins of the smart sensor (the I2C pins on the smart sensor also mux out the UART of the KL05Z). No hardware changes are necessary at all; changing the code running on the smart sensor is all that's required. In fact, during the initial prototyping of the smart sensors, the serial UART connection was used instead of I2C. Modify Aggregator To Use SWD Dongle To Program Smart Sensor:  Add a wire as shown on the bottom side of the aggregator board as shown below. This ties 3.3V on the aggregator to the debug header, enabling the voltage level translators on the dongle to communicate with the KL05Z on the smart sensor board.  

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

Issue Description When WM8960 is working as master mode and target sample rate is 44100Hz or 48000Hz, it's found no sound can be heard on some i.MX boards. Impact Software Baseline: Linux 4.1.15_2.0.0 release or previous versions. Impact Hardware Platform: MCIMX6UL-EVKB, MCIMX6ULL-EVK and MX7SABRE boards which have WM8960 as Audio Codec. Root Cause When WM8960 is working as master mode, if input MCLK is 12.288MHz and configure "PLLPRESCALE =2 and SYSCLKDIV[1:0] =1", wrong BCLK and LRCLK output maybe got on some boards. And then it causes no sound output. Solutions After change the WM8960 PLL setting from “PLLPRESCALE =2 and SYSCLKDIV[1:0] =1” to “PLLPRESCALE =1 and SYSCLKDIV[1:0] =2”, the failure parts can work normally. See attached patch. The formal patch is also included into the releases starting from L4.1.15_2.0.1. See http://git.freescale.com/git/cgit.cgi/imx/meta-fsl-bsp-release.git/tree/imx/meta-bsp/recipes-kernel/linux/files?id=imx_4.1.15_2.0.1

[中文翻译版] 见附件   原文链接： 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.

There are two ethernet ports in i.MX8MP： FEC0 and FEC1(eQOS). Normally we use iperf to test ethernets ports performance. However, when using tftp test, the result is different in two ports. This document describe how to fine tune parameters to increase speed under tftp test or other use case. It is suitable for most i.MX serials and most BSP version.

  Some customer need to config different I2C bus for their PMIC in DDR test period. There is a simple method can complete this, that is NXP DDR Config Tool. The tool download link is below: https://www.nxp.com/design/development-boards/i-mx-evaluation-and-development-boards/config-tools-for-i-mx-applications-processors:CONFIG-TOOLS-IMX I'm going to use the i.MX 93 EVK board here as a demonstration. On i.MX 93 EVK board, the default PMIC I2C Bus is I2C2, I will show you how to change I2C2 to I2C1, the other i2c bus is same.  Step 1 : Rework the board and make sure the PMIC is connected to I2C1. Remove R714 R715, connnect I2C1_SCL(C20) to U701 pin 41  and I2C1_SDA(C21) tp U701 pin 42. Step 2 : Setup I2C1 PinMux: Config Tool UI:   Advance -> IOMUX config   Command:           Address                Size               Value memory   set     0x443c0170            32                   0x10 memory   set     0x443c0174            32                   0x10 memory   set     0x443c0320            32                   0x40000b9e memory   set     0x443c0324            32                   0x40000b9e Step 3 : Set PMIC VDDQ as 1.1 V Config Tool UI:   Advance -> Custom PMIC initialization enabled   #  PMIC commands        Value 0         pmic_cfg             0x0025       /*I2C bus 1,  PMIC address 0x25 */ (0 for I2C1, 1 for I2C2, 2 for I2C3, 3 for I2c4 …) 1         pmic_set             0x0C29       /* BUCKxOUT_DVS0/1, preset_buck1=0.8V, preset_buck2=0.7V, preset_buck3=0.8V PCA9451_BUCK123_DVS, 0x29 */ 2         pmic_set             0x1118      /*  BUCK1OUT_DVS0=0.9V   PCA9451_BUCK1OUT_DVS0, 0x18 */ 3         pmic_set             0x1718      /*  BUCK3OUT_DVS0=0.9V   PCA9451_BUCK3OUT_DVS0, 0x18 */ 4         pmic_set             0x1428      /*  Set VDDQ to 1.1V  PCA9451_BUCK2OUT_DVS0, 0x28  */ PS : About pmic register, The first two bytes are the register address and the next two bytes are the register setting. Step 4 : Run the DDR "Firmware init test" and see the test result. The success log is as follows: DEBUG memtool.comm.serial_channel ==================hardware_init======================= DEBUG memtool.comm.serial_channel DEBUG memtool.comm.serial_channel Power up ddr... DEBUG memtool.comm.serial_channel DEBUG memtool.comm.serial_channel DDRMIX power on done... DEBUG memtool.comm.serial_channel DEBUG memtool.comm.serial_channel DDRPHY coldreset... DEBUG memtool.comm.serial_channel DEBUG memtool.comm.serial_channel DEBUG memtool.comm.serial_channel DEBUG memtool.comm.serial_channel ********Found PMIC PCA945X********** DEBUG memtool.comm.serial_channel DEBUG memtool.comm.serial_channel Set VDDQ to 1.1V for LPDDR4 DEBUG memtool.comm.serial_channel DEBUG memtool.comm.serial_channel ==================hardware_init exit==================    

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.

SW Environment Setup: 1. Prepare L5.10.35 Yocto and build Image  The prebuilt image also is available and useable. 2. Flash image to the SD card  Refer to the Yocto User Guide. 3. Compile flash.bin without M4 and flash it to sdcard (flash.bin as attachment)  make SOC=iMX8QM flash sudo dd if=flash.bin of=/dev/sde bs=1k seek=32 conv=fsync HW Environment Setup: Prepare the imx8qm MEK CPU board and base board and DB9 male cable, connect to CAN0 and CAN1 female connector on base board. (Pin to Pin connection) User Case: 1. Power on board and configure specify dtb file in uboot  setenv fdt_file imx8qm_mek.dtb 2. Boot up and config bitrate for can0 and can1 in kernel root@imx8qmmek:~# ip link set can0 up type can bitrate 500000 root@imx8qmmek:~# ip link set can1 up type can bitrate 500000 3. Check CAN0 and CAN1 devices root@imx8qmmek:~# ifconfig can0: flags=193<UP,RUNNING,NOARP> mtu 16 unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 10 (UNSPEC) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 85 can1: flags=193<UP,RUNNING,NOARP> mtu 16 unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 10 (UNSPEC) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 86 3. Run candump for CAN1 root@imx8qmmek:~# candump can1 & [1] 1215 [ 65.624580] can: controller area network core [ 65.630225] NET: Registered protocol family 29 [ 65.641158] can: raw protocol 4. Run cansend for CAN0 root@imx8qmmek:~# cansend can0 5A1#11.2233.44556677.88 can1 5A1 [8] 11 22 33 44 55 66 77 88   The above red is output result from CAN1.

MAX resolution 1024 x 768 Factory Details:      Long name:    Freescale: Hardware (VPU) Encoder      Class:            Codec/Encoder/Video      Description:    Encodes raw YUV 4:2:0 data to MPEG4 SP, H.264 BP or H.263 (Annex J, K (RS=0 and ASO=0) and T) elementary data;Enco des raw YUV 4:2:0, 4:2:2 horizontal, 4:2:2 vertical or 4:0:0 data into MJPEG elementary data;      Author(s):       Multimedia Team <[email protected]>      Rank:             primary (256) Plugin Details:      Name:                    mfw_vpuencoder      Description:            Encodes Raw YUV Data to MPEG4 SP, H.264 BP or H.263 data. For H.263 P0, the source frame rate must be 3000 0/1001 fps      Filename:               /usr/lib/gstreamer-0.10/libmfw_gst_vpu_enc.so      Version:                  2.0.2      License:                  unknown      Source module:        gst-fsl-plugin      Binary package:       Gstreamer Multimedia Plugins (Freescale)      Origin URL:              http://www.freescale.com GObject   +----GstObject         +----GstElement               +----MfwGstVPU_Enc Pad Templates:    SINK template: 'sink'       Availability: Always       Capabilities:          video/x-raw-yuv                   format: I420                   width: [ 48, 8192 ]                   height: [ 32, 8192 ]        video/x-raw-yuv                   format: YV12                   width: [ 48, 8192 ]                   height: [ 32, 8192 ]        video/x-raw-yuv                   format: NV12                   width: [ 48, 8192 ]                   height: [ 32, 8192 ]        video/x-raw-yuv                   format: Y42B                   width: [ 48, 8192 ]                   height: [ 32, 8192 ]        video/x-raw-yuv                   format: Y444                   width: [ 48, 8192 ]                   height: [ 32, 8192 ]    SRC template: 'src'        Availability: Always        Capabilities:            video/mpeg                             width: [ 48, 1280 ]                           height: [ 32, 720 ]                   mpegversion: 4                 systemstream: false            video/x-h263                             width: [ 48, 1280 ]                            height: [ 32, 720 ]            video/x-h264                             width: [ 48, 1280 ]                            height: [ 32, 720 ]            image/jpeg                             width: [ 48, 8192 ]                            height: [ 32, 8192 ] Element Flags:    no flags set Element Implementation:    Has change_state() function: 0x2b01c98c    Has custom save_thyself() function: gst_element_save_thyself    Has custom restore_thyself() function: gst_element_restore_thyself Element has no clocking capabilities. Element has no indexing capabilities. Element has no URI handling capabilities. Pads:    SRC: 'src'      Implementation:      Pad Template: 'src'    SINK: 'sink'      Implementation:        Has chainfunc(): 0x2b01de28        Has custom eventfunc(): mfw_gst_vpuenc_sink_event        Has bufferallocfunc(): mfw_gst_vpuenc_buffer_alloc      Pad Template: 'sink' Element Properties:    name                : The name of the object                          flags: readable, writable                          String. Default: null Current: "mfwgstvpu_enc0"    codec-type          : selects the codec type for encoding                          flags: readable, writable                          Enum "MfwGstVpuEncCodecs" Default: 2, "std_avc" Current: 2, "std_avc"                             (0): std_mpeg4        - STD_MPEG4                             (1): std_h263           - STD_H263                             (2): std_avc             - STD_AVC                             (7): std_mjpg           - STD_MJPG    profile             : enable time profile of the vpu encoder plug-in                          flags: readable, writable                          Boolean. Default: false Current: false    width               : width of the frame to be encoded                          flags: readable, writable                          Unsigned Integer. Range: 48 - 8192 Default: 48 Current: 0    height              : height of the frame to be encoded                          flags: readable, writable                          Unsigned Integer. Range: 32 - 8192 Default: 32 Current: 0    bitrate             : target bitrate (in kbps) at which stream is to be encoded - 0 for VBR and others for CBR                          flags: readable, writable                          Unsigned Integer. Range: 0 - 32767 Default: 0 Current: 32768    gopsize             : gets the GOP size at which stream is to be encoded                          flags: readable, writable                          Unsigned Integer. Range: 0 - 32767 Default: 30 Current: 30    qp                  : gets the quantization parameter - range is 0-51 - will be ignored for CBR (bitrate!=0)                          flags: readable, writable                          Unsigned Integer. Range: 0 - 51 Default: 15 Current: 4294967295    max-qp              : Maximum quantization parameter for CBR - range is 0-51 for H264 and 1-31 for MPEG4 - lower value brings be tter video quality but higher frame sizes                          flags: readable, writable                          Unsigned Integer. Range: 0 - 51 Default: 51 Current: 4294967295    min-qp              : Minimum quantization parameter for CBR - range is 0-51 for H264 and 1-31 for MPEG4 - lower value brings be tter video quality but higher frame sizes                          flags: readable, writable                          Unsigned Integer. Range: 0 - 51 Default: 0 Current: 4294967295    gamma               : gamma value for CBR - tells VPU the speed on changing qp - lower will cause better video quality                          flags: readable, writable                          Unsigned Integer. Range: 0 - 32768 Default: 24576 Current: 24576    intrarefresh        : 0 - Intra MB refresh is not used. Otherwise - At least N MB's in every P-frame will be encoded as intra MB 's.                          flags: readable, writable                          Unsigned Integer. Range: 0 - 3600 Default: 0 Current: 0    h263profile0        : enable encoding of H.263 profile 0 when codec-type is set to std_h263                          flags: readable, writable                          Boolean. Default: false Current: false    loopback            : disables parallelization for performance - turn off if pipeline with decoder                          flags: readable, writable                          Boolean. Default: true Current: true    intra-qp            : Quantization parameter for I frame. When this value is -1, the quantization parameter for I frames is auto matically determined by the VPU. In MPEG4/H.263 mode, the range is 1.C31; in H.264 mode, the range is from 0.C51. This is ignored for STD_MJPG                          flags: readable, writable                          Unsigned Integer. Range: 0 - 51 Default: 15 Current: 4294967295    crop-left           : The left crop value of input frame to be encoded                          flags: readable, writable                          Unsigned Integer. Range: 0 - 4294967295 Default: 0 Current: 0    crop-top            : The top crop value of input frame to be encoded                          flags: readable, writable                          Unsigned Integer. Range: 0 - 4294967295 Default: 0 Current: 0    crop-right          : The right crop value of input frame to be encoded                          flags: readable, writable                          Unsigned Integer. Range: 0 - 4294967295 Default: 0 Current: 0    crop-bottom         : The bottom crop value of input frame to be encoded                          flags: readable, writable                          Unsigned Integer. Range: 0 - 4294967295 Default: 0 Current: 0    rotation-angle      : Pre-rotation angle - should be 0, 90, 180 or 270                          flags: readable, writable                          Unsigned Integer. Range: 0 - 270 Default: 0 Current: 0    mirror-direction    : mirror direction from source image to encoded image                          flags: readable, writable                          Enum "MfwGstVpuEncMirDir" Default: 0, "none                " Current: 0, "none                "                             (0): none                     - MIRDIR_NONE                             (1): vertical mirroring     - MIRDIR_VER                             (2): horizontal mirroring - MIRDIR_HOR                             (3): both directions       - MIRDIR_HOR_VER    h264-byte-stream    : Generate H.264 byte stream format of NALU. Take effect for H.264 stream only.                          flags: readable, writable                          Boolean. Default: true Current: true

This is a hack to support programming EEPROM I2C devices for MX28 boot. See post at: Re: mx28 boot issues with SSP (SD card) *** USE AT YOUR OWN RISK ***