Update 2 Nov 2016: The work begun with this current sensor board has been superseded by this 4-channel solution. The ribbon cables used below, although easier to solder, were very stiff and tended to lift the sensors off the double sticky foam tape, which endangered the target application board. This post remains for historical purposes. This little board set was put together quickly to measure run current as well as sleep current. The sensor board is intended to be affixed with double sided tape to the board under test. A flat ribbon cable connects to the connection board where the power and current sensor connections may be made. The holes accommodate banana jacks. The current range is selected via the dip switch on the connection board. Below is an image of the schematic. The attached PDF contains the schematic, layout and partial Digikey parts lists along with embedded source files (look for the thumb-tacks).   The DMN1019USN FETs have a Vgs of 8V, which limits the maximum current which may be measured (currents above will starve the output of the current sensor amplifiers since the output cannot swing high enough). With a supply of ~7.5V, a maximum high current of ~3A is possible with the 2V/A gain (A4) version of the INA250. With a 2 Ohm shunt for the low current range, the maximum current with an INA212 (1000V/V gain) is ~3mA. Two FETs in parallel were used to decrease the series resistance when shorting the low current shunt. [NOTE: The voltage applied to the gates of the FETs assumes that the ground on the both board under test and the current sense board combo are in common.  An isolated supply could have been used but was not for simplicity.] The high current range is intended for normal operation, i.e., measuring run currents.The low current range should only be selected once the board is configured for a low power mode. Once in that mode, the low power mode may be selected.  To use an instrumented target board without having to have the connection board hooked up and powered, jump the two vias (spaced 0.1", labeled "Jump" by the current input connections). These vias short the 2 Ohm low current shunt resistor. The target board is connected via the 3-pin header. The outer two points are the negative input connection; the center is the positive. Two negative connections are provided to avoid having to cross the connection wires. These wires should be kept as short as possible. The series resistance at the input in the high range (dip switch off) was under 25mOhms, so the connections wires only add to that. The board set may be used as-is before snapping apart since connections between the boars runs through the row of snap-vias. A ribbon cable needs be used after snapping them apart. Finer pitch ribbon could have been used but it'd be much less friendly for hand soldering. Board sets in multiples of 3 may be ordered here. Here are some photos of the prototype board (some silk screen errors and the banana jack holes were drilled too small). Before snapping apart on the left and after with the ribbon cable and connectors added on the right. Here is a photo of the i.MX6SL on the EVK instrumented for low-power sleep-mode current measurement on VDD_HIGH_IN: SENSOR CALIBRATION CHECK: The calibration of three sensor boards was checked by forcing an accurate, known current with a Keysight B2902A Source Measure Unit (SMU). The average sensor output was measured for each forced current in the high and low range. The data was plotted and best fit lines were applied: The data for each sensor was very linear. The coefficients and offsets of all 6 best fit lines were very similar as can be seen above. The data can be perused in the attached Excel file (HiLo-sensors-1-3-calib.xlsx). The three sets of coefficients for the high range sensor (the INA250A4) were averaged. For each sensor's output, the current was calculated using these averaged coefficients and tabulated next to the forced current (the brown data). All of the calculated currents were within at most 20mA of the actual current forced by the SMU. TO DO: Two outputs are somewhat cumbersome; it'd be handier to just switch which sensor is outputting to the measurement device. It'd also be really handy to have a 4 channel distribution board and 4 sensor boards, which would allow the use of a 4 channel oscilloscope. Some LEDs on the distribution board indicating which measurement range is in use would also be nice... UPDATE 7 OCT 2016: Working now on a Kinetis-based, data-logging capable, 4-channel power profiler for run and sleep. The Kinetis ADCs will be used to measure the sensor outputs and power supply rail voltages, which should be fine given the level of accuracy that is required. Data is sent up the line in real time via a USB serial port, which opens the possibility of the target board profiling it's own power consumption, including low power modes (a wake-up line for the target board is provided for just that purpose). For more information on current measurements in general, see this tutorial series: A Current Sensing Tutorial--Part 1: Fundamentals | EE Times  A Current Sensing Tutorial-Part II: Devices | EE Times  A Current Sensing Tutorial--Part III: Accuracy | EE Times  A Current Sensing Tutorial-Part IV: Layout and Troubleshooting Guidelines | EE Times 

When using Gigabit Ethernet on boards i.MX running Windows 10 IoT Core users may experience network unstability and low latency using build W1809_1_1_0_imx-iotcore. This was fixed by increasing the size of Rx/Tx buffer in ethernet driver. Fix will be part of the next release of BSP, to apply fix to current version a patch was created. To apply patch, copy content of zip archive to appropriate location in folder structure and rebuild BSP.

The Linux L4.1.15_2.1.0 for i.MX 6SLL Release is now available on www.nxp.com.   Files available: # Name Description 1 fsl-yocto-L4.1.15_2.1.0-ga.tar.gz Linux BSP Documentation for L4.1.15_2.1.0. Includes Release Notes, User Guide. 2 L4.1.15_2.1.0-ga_images_MX6SLL.tar.gz i.MX 6SLL EVK Linux Binary Demo Files 3 L4.1.15_2.1.0-ga_mfg-tools.tar.gz i.MX Manufacturing Toolkit for Linux L4.1.15_2.1.0 BSP 4 imx-aacpcodec-4.2.0.tar.gz Linux AAC Plus Codec for L4.1.15_2.1.0   Target boards: i.MX 6SLL EVK Board   Features: See detail features in Release Notes   Known Issues: For known issues and more details please consult the Release Notes.   Information of release, see: README: http://git.freescale.com/git/cgit.cgi/imx/fsl-arm-yocto-bsp.git/tree/README?h=imx-4.1-krogoth ChangeLog: http://git.freescale.com/git/cgit.cgi/imx/fsl-arm-yocto-bsp.git/tree/ChangeLog?h=imx-4.1-krogoth

MIPI can support video streaming over 1, 2, 3 and 4 lanes. On i.MX6 Sabre boards, the OV5640 camera supports 1 or 2 lanes and the NXP Linux Kernel uses 2 lanes as default. In order to use only one lane, follow the steps below: 1 - Change the board Device Tree on Linux Kernel. On file <linux kernel folder>/arch/arm/boot/dts/imx6qdl-sabresd.dtsi, find the entry "&mipi_csi" and change lanes from 2 to 1. 2 - Configure OV5640 to use only one lane instead of two. On file <linux kernel folder>/drivers/media/platform/mxc/capture/ov5640_mipi.c, change the register 0x300e value from 0x45 to 0x05. This register setup is located at struct ov5640_init_setting_30fps_VGA. 3 - Build the kernel and device tree files. 4 - Test the camera. Unit test can be used to test the video capture: /unit_tests/mxc_v4l2_overlay.out -di /dev/video1 -ow 1024 -oh 768 -m 1 5 - Checking if it's really using one lane. MIPI_CSI_PHY_STATE resgister (address 0x021D_C014) provides the status of all data and clock lanes. During video streaming using 2 lanes, the register value constantly changes its value between 0x0000_0300 and 0x0000_0330. When using only one lane, this register value constantly changes its value between 0x0000_0300 and 0x0000_0310. To read the register value during the stream, run the video test with &: /unit_tests/mxc_v4l2_overlay.out -di /dev/video1 -ow 1024 -oh 768 -m 1 & Now, run the memtool: /unit_tests/memtool -32 0x021dc014 1 i.MX6DL running mxc_v4l2_overlay.out with only one lane:

This article explains how to get started with JTAG debugging of the Linux kernel running on the A55 of iMX93EVK. We will be using Lauterbach Trace32 to debug iMX93EVK. Here is a list of pre-requisites that is expected from the readers:- 1. Basic knowledge to get started on Trace32 - Please refer Learning and Training | Lauterbach TRACE32 2. You should have Linux source code and steps to build the kernel. 3. Trace32 Software with a license to debug A55 COMPONENTS   Hardware required: -   iMX93EVK running 6.6.52 BSP Lauterbach Power Debug E40 with a Debug cable Software required: - Trace32 Linux kernel source code   Linux Kernel Modifications Step 1:- In arch/arm64/configs/imx_v8_defconfig, please make sure that:- CONFIG_DEBUG_INFO_REDUCED=n CONFIG_DEBUG_INFO = y CONFIG_KALLSYMS=y   Step-2 :- Enabling JTAG debugging in Linux On iMX93EVK LPUART5 is MUX'd with the JTAG pins gaurav_sharma_0-1744718613352.png   so if we want to debug the linux kernel via JTAG, we will have to disable it. Go to the device tree source file - arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts Change the status of the following node to 'disabled'   gaurav_sharma_1-1744718678374.png   Step 2:- Build the kernel. vmlinux will be created as part of this. This has the Linux kernel along with the debug symbols required for Trace32 debugging. Step-3 At this point either you can copy the linux-imx folder to your local windows machine where Trace32 is installed, or you can simply map the linux machine as a network drive so that the same folder '/opt/samba/nxg05261/linux-imx' is accessible on windows. The motive of this exercise is to use 'vmlinux' and the linux source files present in this folder from trace32 cmm scripts that we will be executing.   Step-4 Replace the newly built kernel 'Image' - arch/arm64/boot/Image with the one present in the boot partition of imx93evk. You can simply copy this Image to iMX93EVK via scp and copy it to the folder - /run/media/boot-mmcblk0p1 Note:- Please make sure that the kernel version that is running on the box and the one you have built should be the same otherwise there will be debug symbols mismatch After copying the Image, reboot iMX93EVK. Debugging with Trace32 Step-1 Configuring Uboot bootargs Cpu idle state interferes with the JTAG debugging by impacting the clocks so we need to disable the cpu idle power management. We do this by appending "cpuidle.off=1" to the bootargs:- a. Stop at Uboot prompt. b. Execute command - setenv mmcargs "setenv bootargs ${jh_clock} ${mcore_clk} console=${console} root=${mmcroot}  cpuidle.off=1" [do not omit the inverted commas in the command] Step-2 Boot to Linux prompt   Step-3 Connect the USB cable of Lauterbach Power Debug probe to your windows machine and Open t32 - C:\T32\bin\windows64\t32start.exe   gaurav_sharma_5-1744718944949.png Select 'PowerView Instance' and click on 'Start'. A window like below will appear: -   gaurav_sharma_6-1744719062494.png Step- 4 Extract MMU translation info for the debugger For this either you can execute the below commands on the T32 in sequence: -   RESet SYStem.RESet SYStem.CPU IMX93-CA55 SYStem.JtagClock 10MHz SYStem.CONFIG.DEBUGPORTTYPE JTAG SYStem.Option EnReset OFF CORE.ASSIGN 1. 2. SYStem.Option MMUSPACES ON SYStem.Option IMASKASM ON SYStem.Mode Attach Data.LOAD.Elf <path_of_vmlinux> /NoCODE DO ~~/demo/arm/kernel/linux/board/generic-template/detect_translation.cmm OR simply edit the attached cmm script - detect_address_translation.cmm and modify the <path_of_vmlinux> as per your file location. Then execute it like this:- Do <file_path>/detect_address_translation.cmm In my case, this command was: - Do C:\Users\nxg05261\Documents\cmm_scripts\detect_address_translation.cmm Note:- <path_of_vmlinux> in my case was  C:\T32\demo\arm\bootloader\uboot\vmlinux. You can modify it as per the location where you have copied 'vmlinux' -- After executing the above commands, debugger address translation will be displayed: -  gaurav_sharma_8-1744719186783.png   Now we will copy the above highlighted lines and paste it in the final cmm script that we will use for debugging. For readers' convenience this info has been collated into the final script - 'linux_attach_t32.cmm', attached with this blog.   Disclaimer:- The lines that are highlighted depends on the kernel version and customer design decisions, so it is strongly advised to take the output of detect_translation.cmm for your system and then paste it in the cmm script, instead of using the exact output that I have shown in the above picture. File -> Open File -> linux_attach_t32.cmm gaurav_sharma_9-1744719239784.png -- Click on 'Do' button to execute the script till the end. gaurav_sharma_0-1744719677000.png -- Set a breakpoint at start_kernel b.s start_kernel /Onchip   [Optional]Check the breakpoint via 'b.l'   gaurav_sharma_1-1744719798475.png -- Hit 'go' at t32 to let the cores execute the instructions, you will see 'running' state   gaurav_sharma_2-1744719826022.png -- Enter 'reboot' at Linux prompt and stop at Uboot command line prompt you will see trace32 at 'system down' state: - gaurav_sharma_3-1744719897706.png -- Execute 'system.mode.attach' at t32 to attach to the system, you will again see 'running' state -- Execute 'break' to stop the running state -- Check if the breakpoint 'start_kernel' still exist via command 'b.l' -- If you see the breakpoint is still set, Execute 'go' at t32 to take the cores to the running state. -- Then, at Uboot prompt, execute 'boot' so that it may load the linux kernel to the memory.   As soon as you do that you would see that Uboot will try to load kernel. The last print you will see on the serial console will be: - "Starting kernel …' the execution will stop and at t32 you will see that the breakpoint is hit, meaning the Program Counter is at the address of the function 'start_kernel' gaurav_sharma_4-1744720057810.png   Note- The Warning that you might observe[like in the above picture] means that trace32 is not able to find the source file 'main.c'. So you will not be able to see the 'C' source code at this point. To resolve this:- -- Right click on the 'List.auto' window where you see the assembly code. Click on 'Resolve Path' and navigate to the init/main.c in your kernel source code folder and click Open. You would see that the source path translation is now correct and you're able to view the disassembly as well as the source code: -   gaurav_sharma_5-1744720161325.png   Now we will load kernel symbols and apply 2 breakpoints in the linux kernel to demonstrate kernel debugging:-   -- Load the kernel symbols Data.LOAD "C:\T32\demo\arm\bootloader\uboot\vmlinux"  H:0x0::0x0 /NoCODE /SOURCEPATH Z:\linux-imx gaurav_sharma_6-1744720206901.png   -- Apply breakpoints at t32 window b imx_rpmsg_init b imx_drm_bind   [Optionally] you can verify the breakpoints via 'b.l' gaurav_sharma_0-1744781339510.png These breakpoints are temporary as you can see in the above snapshot. That means after they are hit, they will be removed, so to make them permanent:- Right click the breakpoint -> Change -> Uncheck Temporary -> Click Ok like depicted in the following snapshots: - gaurav_sharma_1-1744781477140.png   gaurav_sharma_2-1744781531859.png   gaurav_sharma_7-1744720262647.png   Now, to reach the next breakpoint, execute 'go' on the t32 gaurav_sharma_8-1744720292331.png At this point linux kernel execution has reached the function imx_rpmsg_init   Again, to reach the next breakpoint, execute 'go' gaurav_sharma_0-1744720569015.png   So this is how you start debugging the linux kernel. Apart from this, there is a nice t32 feature called 'linux awareness' which allows you to easily debug the kernel loadable modules, user space applications amongst other things. To explore 'linux awareness', you can go about checking the 'Linux' drop down menu present at the top. Plenty of support documents are available on the web.   gaurav_sharma_1-1744720601236.png   gaurav_sharma_2-1744720619336.png   Feel free to drop in the comments section or DM if you have any queries. Happy debugging!!🙂🙂🙂🙂  

BSP: L6.1.36 Some customer need use adb under usb ffs. The adb in Yocto can greatly improves development efficiency. This is a demo for enabling adb on Yocto.   Yocto local.conf IMAGE_INSTALL:append = "android-tools android-tools-adbd" PREFERRED_PROVIDER_android-tools-conf = "android-tools-conf-configfs"   Test script for launching adbd modprobe g_ffs idVendor=0x1fc9 idProduct=0x0146 iSerialNumber="ZhimingLiu" mkdir -p /dev/usb-ffs/adb mount -t functionfs adb /dev/usb-ffs/adb -o uid=2000,gid=2000 adbd &   Test on Windows: PS C:\Users\Administrator\Desktop\platform-tools> .\adb.exe devices List of devices attached ZhimingLiu device PS C:\Users\Administrator\Desktop\platform-tools> .\adb.exe shell sh-5.2# uname -a Linux imx8mp-lpddr4-evk 6.1.36+g04b05c5527e9 #1 SMP PREEMPT Fri Nov 24 04:46:22 UTC 2023 aarch64 GNU/Linux sh-5.2# ls config ffs t.sh test2.sh sh-5.2# cd / sh-5.2# ls bin dev home lost+found mnt proc run srv tmp usr boot etc lib media opt root sbin sys unit_tests var sh-5.2#

Platform i.MX8MPlus EVK, Android 13 Background Customer find we have enabled all configs about pstore and ramoops, but they can't get ramoops log in /sys/fs/pstore node on Android 13. Solution The default reboot will reset all hardware including the DDR control, so this will result in the loss of the log stored in RAM. We have include such codes in ATF, the default code will use imx_wdog_restart(true) to reset all hardware. void __dead2 imx_system_reset(void) { #ifdef IMX_WDOG_B_RESET imx_wdog_restart(true); #else imx_wdog_restart(false); #endif }   To avoid DDR reset, we should comment  IMX_WDOG_B_RESET in vendor/nxp-opensource/arm-trusted-firmware/plat/imx/imx8m/imx8mp/include/platform_def.h Zhiming_Liu_0-1693468718652.png   Result evk_8mp:/sys/fs/pstore # ls console-ramoops-0 dmesg-ramoops-0 pmsg-ramoops-0  

Symptoms   Bridge mode on EQoS module will not work since Linux Kernel 5.10_2.2.0. Platforms impacted: i.MX8MP/i.MX8DXL/i.MX93   Diagnosis   When eqos module(eth1) is added to the bridge using brctl, it will first set eth1 to promiscuous mode and then set the VLAN for this bridge with a filter VID value of 1. Before adding Intel's patch, there is no problem. c89f44ff10fd net: stmmac: Add support for VLAN promiscuous mode However, when Intel's patch sets up the filter, if it finds that the promiscuous mode is turned on, it will turn off the VLAN Tag function. And it adds a judgment on whether promiscuous mode has been turned on in the function of configuring VID. Returns an error if promiscuous mode is found. Because the patch has turned off the VLAN tag function when promiscuous mode is enabled, which conflicts with continuing to configure the VID. Workaround   This patch is okay for aarch64 platform to solve this issue. diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c index c25bfecb4a2d..2dc548b54b1c 100644 --- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c @@ -481,12 +481,6 @@ static int dwmac4_add_hw_vlan_rx_fltr(struct net_device *dev, if (vid > 4095) return -EINVAL; - if (hw->promisc) { - netdev_err(dev, - "Adding VLAN in promisc mode not supported\n"); - return -EPERM; - } - /* Single Rx VLAN Filter */ if (hw->num_vlan == 1) { /* For single VLAN filter, VID 0 means VLAN promiscuous */ @@ -536,12 +530,6 @@ static int dwmac4_del_hw_vlan_rx_fltr(struct net_device *dev, { int i, ret = 0; - if (hw->promisc) { - netdev_err(dev, - "Deleting VLAN in promisc mode not supported\n"); - return -EPERM; - } - /* Single Rx VLAN Filter */ if (hw->num_vlan == 1) { if ((hw->vlan_filter[0] & GMAC_VLAN_TAG_VID) == vid) {  

some industry customer to use i.MX8MM will use RMII to link the 100Mhz ethernet phy and wish to use our i.mx8mm output 50Mhz reference clock to external phy to save a crystal, this doc and patch explain how to support it. SW: Linux BSP 5.10.17. HW: i.MX8MM LPDDR/DDR EVK board. 中文版本为一个完整的如何支持一个100Mhz以太网PHY  

This is simple known-how for how to implement "boot animation" with DRM under i.MX8/X + Linux:   Code to refer to: ========================================================================= 1. kmscube: Either open source one or the customized on for i.MX will be OK: https://cgit.freedesktop.org/mesa/kmscube/ https://source.codeaurora.org/external/imx/kmscube-imx/ 2. Android display HAL: KmsDisplay.cpp   Known-how: ========================================================================= 1. Only one application can grab the master role of the DRM device. If need to control DRM from two applicaiton simultanously, possible solution:     A, Use "controlD" node instead of "card" node in /dev/dri/. This requires L4.14 or before. This device node was removed by two commits in L4.14.x:           8a357d10043c75e980e7fcdb60d2b913491564af           6449b088dd51dd5aa6b38455888bbf538d21f2fc     Can be brought back by reverting these two commits in L4.14.98.     B, Use framebuffer emulator to emulate a FB device (/dev/fb0). (not recommended due to lack of vsync). 2. Some kernel functions will re-config the DRM device during boot. This will cause display abnormal after user application has configured the DRM device. Better to disable these kernel features:       CONFIG_DRM_FBDEV_EMULATION       CONFIG_FRAMEBUFFER_CONSOLE 3. Use atomic mode of KMS API instead of legacy mode for any dynamically screen drawing application, such as video, game and etc. Atomic mode will have much better performance compare to legacy mode. The kmscube has sample code for both mode. 4. Better to do commit checking before doing any real commit, especially when doing display during boot. Sometimes some internal component in DRM is not fully ready after card device is present.       DRM_MODE_ATOMIC_ALLOW_MODESET 5. If video playback will be used, some points to remind:     a, Sample code for direct video decoding (in unit-test): imx-test/test/mxc_v4l2_vpu_test/     b, VPU in i.MX8/X only support tiled NV12 output and it has pixel alignment requirement (128). Need to use CPU or G2D to do un-tile, CSC and cropping. Sample code: <android>/vendor/nxp/fsl_imx_omx/OpenMAXIL/src/component/v4l2_common/G2dProcess.cpp If using G2D under Linux, it will support un-tile directly (through OpenCL internally).

ro.hwui.disable_scissor_opt For Vivante GPU, the scissor should be enabled. The default value is enabled, So, keep the default value. ro.hwui.texture_cache_size ro.hwui.layer_cache_size ro.hwui.r_buffer_cache_size ro.hwui.path_cache_size ro.hwui.drop_shadow_cache_size These parameters depend on display resolution. The default value is calculated according to 720P resolution which near 1024x768 resolution on our platform. ro.hwui.text_small_cache_width ro.hwui.text_small_cache_height ro.hwui.text_large_cache_width ro.hwui.text_large_cache_height These variables depends on screen resolution, density(similar to ppi) and language used. On a larger resolution screen, there might be more characters painted on it. Better to have larger font cache size. On a larger density config, it tends to use larger fonts. If the language has more different characters (symbols), it may need larger texture size to cache the fonts. For example, English may only have 52 characters, but Chinese have more than 10K and each will occupy more memory cache than English character. If cache size is too small, performance may drop because the font renderer will flush existed cache and upload new ones. If cache size is too large, it just wastes memory. It's OK to flush existed cache sometimes. But it's better to have only one (or no) flush for rendering a single screen. The default value is optimum on out platform with 1024x768 display resolution. BTW, texture size limitation on current Vivante GPU are 8192 x 8192.

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

  IMX6 S/DL for consumer has both PXP and IPU. Automotive and Industrial versions doesn't have PXP. As IMX6 also has IPU, the Linux framebuffer driver uses IPU and not PXP. Note : “pxp_v4l2_test.out” from unit_tests was made for processors (i.MX6 SL), that have only PXP and its framebuffer driver applies PXP to accelerate image processing. “pxp_v4l2_test.out” should not be used with i.MX6 S/DL. To test PXP device with i.MX6 S/DL users have to try “pxp_test.out”.

Hi, The document "How to create ubuntu hardfloat rootfs for imx6d/q" was shared by Junping Mao. https://community.freescale.com/docs/DOC-95185 However, some modification need to be made to build imx-tests on this rootfs. Attached please find the guide for building imx-tests on hf-ubuntu rootfs for imx6d/q. Any problems, pls feel free to let me know. Regards, Alvin zheng

For most of interlace output camera sensors, they only support up to 30fps sample rate. In this case, we may not get good display quality. In order to improve the permance under this case, we can use IPU VDI function to increase the output frequency to be 60fps and then we can get a better quality. The patch is an example to support YUV422(YUYV) 60fps VDI for Android camera preview. SW Platform: kk4.4.2_1.0.0-ga HW Platform: imx6q-sabresd Features: Support YUV422(YUYV) input format; Support IPU 60fps VDI; Supprot 60fps camera preview, but don't support camera capture. Patch: The linux kernel patch to support additonal IPU function can be found at: https://community.freescale.com/docs/DOC-173003 The Android Camera HAL can be found at here. Note: 1. The g_vdi_double is used to decide whether to support these features. When g_vdi_double is set to be 1, these features will be enabled; Or these features will be disabled and camera feature will be the same with default release. 2. The patch should be used at hardware\imx\mx6\libcamera2. 3. Accoeding to the real user case, the user can set IPU VDI motion mode to be 0 or 1 , but NEVER to be 2. 4. The fps can be up to 60fps, but it is not stable now.

On imx8qm there are two DPUs(display process unit) and one ISI(image subsystem interface), ISI has 5 inputs and two of them are from DPU0 and DPU1.   This document demonstrates on how to loopback DPU1 outputs to ISI. Note that only mipi dsi0 of dpu0 and lvds1 of dpu1 can be loopbacked to isi.   Platform:                            imx8qm b0 mek OS:                                    yocto 4.14.78 ga hardware connection:        imx8qm lvds1 ====> it6263 cable =====> hdmi display.   1st: isi has 8 pipelines which can be assigned to any of the 5 inputs, this doc takes the 5th pipeline to sink the dpu1 input. So you will need to configure the isi_4( start from 0) source in the dts and write a simple v4l2 subdev for capture testing, the default isi_4 device will be /dev/video4.   2st: configure both framegen0 of dpu1 and lvds1's link to pixellink 3.   3st: write a v4l2 userspace program to capture from /dev/video4 device, take this vulkan-capture as an example. Note that Vulkan-capture is rendered by vulkan api, you can also take opengl es for rendering.   See the atttachments for details.   ======================================== 2019/11/12 update patches. ======================================== 2019/12/19 add patch. Support connect real display to DC1-LVDS1   Note: for ISI loopback,  it needs output of 2x GPIO (4x for HDMI-TX or combo PHY) to pixel_link_receiver_address: For iMX8QM: o LVDS: pixel_link_receiver_address[1:0] = do_gpio_dr[7:6]  o MIPI-DSI: pixel_link_receiver_address[1:0] = do_gpio_dr[7:6] o HDMI-TX: odd_pixel_link_receiver_address[1:0] = do_gpio_dr[7:6],even_pixel_link_receiver_address[1:0] = do_gpio_dr[5:4]   For iMX8QXP: o Combo MIPI-DSI / LVDS: pixel_link0_receiver_address[1:0] = do_gpio_dr[7:6], pixel_link1_receiver_address[1:0] = do_gpio_dr[5:4] 

Important: If you have any questions or would like to report any issues with the DDR tools or supporting documents please create a support ticket in the i.MX community. Please note that any private messages or direct emails are not monitored and will not receive a response.   This is a detailed programming aid for the registers associated with MMDC initialization. The last sheet formats the register settings for use with ARM RealView ICE. It can also be used with the windows executable for the DDR Stress Test. This programming aid was used for internal NXP validation boards.

This sharing introduces how to porting the deepseek to the #i.MX8MP i.MX93EVK  with the Yocto BSP by llama.cpp The main test model used in this document is the Qwen model that is distilled and quantized based on the deepseek model. For other versions of the deepseek model, you can refer to the steps in the document to download different models for testing. 1. Set up the demo ON PC a. Prepare the cross-compiling. See the i.MX Yocto Project User's Guide for detailed information how to generate Yocto SDK environment for cross-compiling. Get the User's Guide. To activate this Yocto SDK environment on your host machine, use this command:   :$ source <Yocto_SDK_install_folder>/environment-setup-cortexa53-crypto-poky-linux   b. Cross-compile the llama.cpp eg: i.MX93   :$ git clone https://github.com/ggerganov/llama.cpp :$ mkdir build_93 :$ cd build_93 :build_93$ cmake .. -DCMAKE_SYSTEM_NAME=Linux -DCMAKE_SYSTEM_PROCESSOR=aarch64 -DCMAKE_C_COMPILER=aarch64-poky-linux-gcc -DCMAKE_CXX_COMPILER=aarch64-poky-linux-g++ :build_93$ make -j8 :build_93$ scp bin/llama-cli root@<your i.MX93 board IP>:~/ :build_93$ scp bin/*.so root@<your i.MX93 board IP>:/usr/lib/   c. Get the DeepSeek model on the huggingface eg: Dowload the DeepSeek-R1-Distill-Qwen-1.5B-Q4_K_M.gguf model Download the required Deepseek model in the huggingface. ON Board a.Test the Deepseek on the i.MX93 board   :~/# ./llama-cli --model DeepSeek-R1-Distill-Qwen-1.5B-Q4_K_M.gguf     b. Results shown below: Yuhao_Ning_7-1740641971221.png   2. Results Analysis The effects of different models on different boards were tested. It should be noted that the biggest obstacle limiting the running of the model on the board is memory.The test results including CPU and memory usage are as follows: a. i.MX8mp + DeepSeek-R1-Distill-Qwen-7B-IQ4_XS Yuhao_Ning_8-1740641971235.png Yuhao_Ning_9-1740641971250.png b. i.MX93 + DeepSeek-R1-Distill-Qwen-1.5B-Q4_K_M Yuhao_Ning_10-1740641971265.png Yuhao_Ning_11-1740641971283.png   After testing, the speed at which i.MX8MP runs DeepSeek-R1-Distill-Qwen-7B-IQ4_XS to generate tokens is about 1 token per second. The speed at which i.MX93 runs DeepSeek-R1-Distill-Qwen-1.5B-Q4_K_M to generate tokens is about 1.6 token per second.  The above test results for the generation speed are only rough test results and are for reference only. The above icons show the CPU and memory usage of i.MX during the DeepSeek model running. It should be pointed out that the CPU efficiency affects the speed of model token generation. The memory size of the board limits whether the model can run in the corresponding development board. This is a balance between running speed and required memory size. Higher accuracy, such as using a 7B model, will result in a decrease in running speed.

Here are some debug methods for kernel performance requirements or related issues. It includes all the common methods such as oops/panic issues, memory issues, and so on. Please check it in the attachments for details. OS and System analysis Oops/Panic case addr2line objdump gdb Pstore Kdump Memory debugging SLAB KASAN Kmemleak Performance Perf Ftrace eBPF/bcc

This is a hardware design checklist for i.MX28. Please go through this checklist and check your design before requesting a schematics review. Arthur