After rework the board, enable two OTG controllers in Linux DTB file and disable VBUS valid comparator when in suspend mode by clear USB_OTGx_PHY_CTL2 bit 16.  Then we get the following power data on suspend mode  Suspend Mode     ****  The page is under internal check ****

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

Following OTA in Android User Guide would have HASH verification error: update_engine: [0913/085233.421711:ERROR:delta_performer.cc(1140)] Expected: sha256|hex = 685B998E4308F20FEA83D97E60222121FFE27983F013AED5C203709E139AE9DB update_engine: [0913/085233.421760:ERROR:delta_performer.cc(1143)] Calculated: sha256|hex = B1025634138BF2B5378196E364350E1E5FCA126DEE0990A592290CEBFADC3F8B The OTA process that produced the error: * After compiling the images according to the user guide, burn the images in the /out directory into the board * Then build the first target file according to 7.1.1 Building target files, such as PREVIOUS-target_files.zip * Modify part of the code to build the second target file, such as NEW-target_files.zip: * Make a differential upgrade package and perform differential OTA The root cause of the error caused by the above steps: Differential OTA requires that the onboard system.img must be the system.img generated when the target files are created for the first time. Only in this way can the correct hash value be calculated. When we execute the following command to make target files make target-files-package -j4 Will repackage a copy of system.img in the /out directory and this system.img does not meet the requirements. The system.img used by the differential package must be system.img in out/target/product/evk_8mm/obj/PACKAGING/systemimage_intermediates/. Therefore, the system.img we burned in the first step did not meet the requirements, resulting in hash verification errors. Solution 1: After the first step of programming, do a full update. When using the make otapackage -j4 command, a target_files.zip file will also be generated, which we will regard as PREVIOUS-target_files.zip. Modify part of the code and make NEW-target_files.zip. Finally, the differential upgrade can be successful. Solution 2: After finishing the first target_files.zip, copy the system.img in out/target/product/evk_8mm/obj/PACKAGING/systemimage_intermediates/ to the out/target/product/evk_8mm directory, and then use uuu Perform programming. After burning and writing, make the second target_files.zip, and finally you can upgrade by differential.

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

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

Usually, device tree source files are not a signal pure dts file. It could include dtsi, dts or C code heads .h files. Need C compiler finish the pre-compile to a pure dts file first. It is integrated inside the like Linux build system(Makefile, etc.). This document shows the original way to compile device tree. This document will show compile device tree under windows.    

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.    

[中文翻译版] 见附件   原文链接： eIQ Machine Learning Software for i.MX Linux 4.14.y 

test ov5640 with 480p, raw10 via ISP on imx8mp

[中文翻译版] 见附件   原文链接： Add a new shared memory region on Android Auto P9.0.0_GA2.1.0 BSP 

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

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

  Solution           

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

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

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

This article is rather short that only mentions the script that is needed to make an iMX93EVK act as a USB mass storage device so that whenever you connect your iMX device to a windows/linux system via USB, it should get enumerated something like a usb drive.  The storage that is used in this example is mmc so the expectation is that you have inserted a mmc card in the slot. Below is the script:- #!/bin/sh   # This composite gadget include function: # - MASS STORAGE     # # Exit status is 0 for PASS, nonzero for FAIL # STATUS=0   # Check if there is udc available, if not, return fail UDC_DIR=/sys/class/udc if test "$(ls -A "$UDC_DIR")"; then echo "The available udc:" for entry in "$UDC_DIR"/* do echo "$entry" done else STATUS=1 echo "No udc available!" exit $STATUS; fi   id=1; udc_name=ci_hdrc.0 #back_file=/dev/mmcblk1 back_file=/tmp/lun0.img   mkdir /sys/kernel/config/usb_gadget/g$id cd /sys/kernel/config/usb_gadget/g$id   # Use NXP VID, i.MX8QXP PID echo 0x1fc9 > idVendor echo 0x12cf > idProduct   mkdir strings/0x409 echo 123456ABCDEF > strings/0x409/serialnumber echo NXP > strings/0x409/manufacturer echo "NXP iMX USB Composite Gadget" > strings/0x409/product   mkdir configs/c.1 mkdir configs/c.1/strings/0x409   echo 5 > configs/c.1/MaxPower echo 0xc0 > configs/c.1/bmAttributes   mkdir functions/mass_storage.1 echo $back_file > functions/mass_storage.1/lun.0/file ln -s functions/mass_storage.1 configs/c.1/   echo $udc_name > UDC First execute the script. After that insert the g_mass_storage module in the kernel by executing :- modprobe g_mass_storage file=/dev/mmcblk1 removable=1 In the dmesg output, you will see something like below:-   After that you can connect a C type USB cable to the USB1 port of imx93evk and the other end to any USB ports of a laptop. The moment it is connected, you would be able to see a USB drive similar to what you get when we connect a pen-drive. 

Sometime need standalone compile device tree. Only Linux headers and device tree directory are needed.         

What is LGVL? LVGL is a graphics library to run on devices with limited resources. LVGL is fully open-source and has no external dependencies, works with any modern MCU or MPU, and can be used with any (RT)OS or bare metal setup. https://lvgl.io/   What is Framebuffer? The Linux framebuffer (fbdev) is a Linux subsystem used to show graphics on a display, typically manipulated on the system console   How to write on the frame buffer? The device is listed on de device list typically "fb0" on iMX.   1. Stop the window manager (Weston in our BSP) $ systemctl stop weston   2. Write random data on the frame buffer with the next command: $ cat /dev/urandom > /dev/fb0   You should see colored pixels on the screen   3. Restart the window manager. $ systemctl start weston     Cross-compiling the application   1. On the host computer we will clone the LGVL repo: $ git clone https://github.com/lvgl/lv_port_linux_frame_buffer.git -b release/v8.2 $ cd lv_port_linux_frame_buffer $ git submodule update --init --recursive 2. Configure the screen resolution, rotation, and the touch input.       2.1 The resolution is configured in lines 33 and 34 of the main.c disp_drv.hor_res = 1080; disp_drv.ver_res = 1920;           2.2 Rotation configured is on lines 32 and 57 of main.c. disp_drv.sw_rotate = 3; lv_disp_set_rotation(NULL, LV_DISP_ROT_270);     2.3 The touch input is configured on line 450 of lv_drv_conf.h # define EVDEV_NAME "/dev/input/event2"   Note: In my case is on /dev/input/event2 to check the inputs use the command "evtest"   3. Compile the application using the command "make"   Note: To compile the application on your host computer you have to set the environment.   4. Share the file called "demo" with your board and execute it on the board with the command $ ./demo   Note: You have to stop the weston service to run the application.     Notes: Tested on iMX8MN EVK with BSP 6.1.36 Works on Multimedia and Full image.

P3T1755DP is a ±0.5°C accurate temperature-to-digital converter with a -40 °C to +125 °C range. It uses an on-chip band gap temperature sensor and an A-to-D conversion technique with overtemperature detection. The temperature register always stores a 12-bit two's complement data, giving a temperature resolution of 0.0625 °C P3T1755DP which can be configured for different operation conditions: continuous conversion, one-shot mode, or shutdown mode.   The device has very good features but, unfortunately, is not supported by Linux yet!   The P31755 works very similarly to LM75, pct2075, and other compatibles.   We can add support to P3T1755 in the LM75.c program due to the process to communicate with the device is the same as LM75 and equivalents.   https://github.com/nxp-imx/linux-imx/blob/lf-6.1.55-2.2.0/drivers/hwmon/lm75.c route: drivers/hwmon/lm75.c   The modifications that we have to do are the next:    1. We have to add the configurations to the kernel on the imx_v8_defconfig file CONFIG_SENSORS_ARM_SCMI=y CONFIG_SENSORS_ARM_SCPI=y CONFIG_SENSORS_FP9931=y +CONFIG_SENSORS_LM75=m +CONFIG_HWMON=y +CONFIG_I2C=y +CONFIG_REGMAP_I2C=y CONFIG_SENSORS_LM90=m CONFIG_SENSORS_PWM_FAN=m CONFIG_SENSORS_SL28CPLD=m    2. Add the part on the list of parts compatible with the driver LM75.c enum lm75_type { /* keep sorted in alphabetical order */ max6626, max31725, mcp980x, + p3t1755, pct2075, stds75, stlm75,   3. Add the configuration in the structure lm75_params device_params[]. .default_resolution = 9, .default_sample_time = MSEC_PER_SEC / 18, }, + [p3t1755] = { + .default_resolution = 12, + .default_sample_time = MSEC_PER_SEC / 10, + }, [pct2075] = { .default_resolution = 11, .default_sample_time = MSEC_PER_SEC / 10,   Notes: You can change the configuration of the device using .set_mask and .clear_mask, see more details on LM75.c lines 57 to 78   4. Add the ID to the list in the structure i2c_device_id lm75_ids and of_device_id __maybe_unused lm75_of_match    { "max31725", max31725, }, { "max31726", max31725, }, { "mcp980x", mcp980x, }, + { "p3t1755", p3t1755, }, { "pct2075", pct2075, }, { "stds75", stds75, }, { "stlm75", stlm75, },   + { + .compatible = "nxp,p3t1755", + .data = (void *)p3t1755 + },   5. In addition to all modifications, I modify the device tree of my iMX8MP-EVK to connect the Sensor in I2C3 of the board.  https://github.com/nxp-imx/linux-imx/blob/lf-6.1.55-2.2.0/arch/arm64/boot/dts/freescale/imx8mp-evk.dts   }; }; + + p3t1755: p3t1755@48 { + compatible = "nxp,p3t1755"; + reg = <0x48>; + }; + };   Connections: We will use the expansion connector of the iMX8MP-EVK and J9 of the P3T1755DP-ARD board.   P3T1755DP-ARD board   iMX8MP-EVK   P3T1755DP-ARD ----> iMX8MP-EVK J9              ---------->            J21 +3v3 (Pin 9) ---> +3v3 (Pin 1) GND(Pin 7) ---> GND (PIN 9) SCL (Pin 4) ---> SCL (Pin 5) SDA (Pin 3) ---> SDA (Pin 3)     Reading the Sensor We can read the sensor using the next commands:   Read Temperature: $ cat /sys/class/hwmon/hwmon1/temp1_input Reading maximum temperature: $ cat /sys/class/hwmon/hwmon1/temp1_max Reading hysteresis: $ cat /sys/class/hwmon/hwmon1/temp1_max_hyst   https://www.nxp.com/design/design-center/development-boards-and-designs/analog-toolbox/arduino-shields-solutions/p3t1755dp-arduino-shield-evaluation-board:P3T1755DP-ARD