i.MX8/i.MX8X/i.MX8DXL has ddr stress test tool. It is a window UI program. In some cases, i.MX devices is security closed. Need signed image to run. Such as unit fail field return analyze, switch new ddr part on existing board.  

Useful information about push buttons.   Physical level.            When there is a change of voltage level on P0-P7 pins, PCA9555PW will generate interrupt on INT pin. The driver (running on SoC) can read the status of P0-P7 pins via I2C (SCL/SDA pins) and generate separate interrupts for each of P0-P7 pins. This is why this driver acts as interrupt controller. Consider next configuration:        One push button changes level on P4 pin, tempting PCA9555PW to generate interrupt. Interrupt from PCA9555PW is connected to GPIO5 IP-core (inside of SoC), and it uses line #9 of that GPIO5 module to notify CPU about interrupt. So we can say that PCA9555PW is cascaded to GPIO5 controller. GPIO5 also acts as interrupt controller, and it's cascaded to GIC interrupt controller.   Device tree properties.   The meaning of properties is as follows: interrupt-controller  property defines that device generates interrupts; it will be needed further to use this node as interrupt-parent in each push button node. #interrupt-cells defines format of interrupts property; in our case it's 2 : 1 cell for line number and 1 cell for interrupt type interrupt-parent and interrupts properties are describing interrupt line connection   Interrupt handling.   CPU now is in interrupt context in GIC interrupt handler. From gic_handle_irq() it calls handle_domain_irq() , which in turn calls generic_handle_irq() . See Documentation/gpio/driver.txt for details. Now we are in SoC's GPIO controller IRQ handler. SoC's GPIO driver also calls generic_handle_irq() to run handler, which is set for each particular pin. See for example how it's done in omap_gpio_irq_handler() . Now we are in PCA9555PW IRQ handler. PCA9555PW IRQ handler calls handle_nested_irq() . Finally, gpio_keys_gpio_isr() is called.      The following steps allow you to enable rgb led's and push buttons on 8MIC-RPI-MX8 board with i.MX 8M Mini Applications Processor Evaluation Kit (EVKB). You have to use a led driver and change the device tree. On the Host. Cloning the Linux kernel repository.   Clone the i.MX Linux Kernel repo to the home directory. cd ~ git clone https://source.codeaurora.org/external/imx/linux-imx This guide will use the following commit which corresponds to Kernel 5.10.35-2.0. cd linux-imx/ git checkout -b RGB ef3f2cfc6010 Patching the device tree.   Download the "0001-Enable-RGB-LED-s-and-push-buttons-on-8MIC-RPI-MX8-bo.patch" file attached to this post and copy it into linux-imx directory, then apply the patch. cp 0001-Enable-RGB-LED-s-and-push-buttons-on-8MIC-RPI-MX8-bo.patch ~/linux-imx/ cd ~/linux-imx/ patch < 0001-Enable-RGB-LED-s-and-push-buttons-on-8MIC-RPI-MX8-bo.patch When prompted, select the file to patch: File to patch: arch/arm64/boot/dts/freescale/imx8mm-evk-8mic-revE.dts patching file arch/arm64/boot/dts/freescale/imx8mm-evk-8mic-revE.dts Then setup your toolchain, for example: source /opt/fsl-imx-wayland/5.10-hardknott/environment-setup-cortexa53-crypto-poky-linux Generate config file. make imx_v8_defconfig Compile the device tree. make freescale/imx8mm-evk-8mic-revE.dtb Copy the .dtb file to the EVK, for example with scp: scp imx8mm-evk-8mic-revE.dtb root@<EVK_IP>:/home/root Alternatively, you may copy the .dtb file directly to the FAT32 partition where the Kernel and Device Tree files are located. Compiling the Led driver.   Obtain the leds-pca995x.h file in the next site: https://github.com/TechNexion/linux-tn-imx/blob/tn-imx_5.4.70_2.3.0-stable/include/linux/platform_data/leds-pca995x.h  Copy it into the next path: cp leds-pca995x.h ~/linux-imx/include/linux Create a new directory. mkdir ~/linux-imx/PCA9955 Create a makefile. cd ~/linux-imx/PCA9955 vim Makefile   KERNEL_ROOT?=~/linux-imx obj-m += leds-pca995x.o all: make -C $(KERNEL_ROOT) M=$(PWD) modules clean: make -C $(KERNEL_ROOT) M=$(PWD) clean   Press the key "Esc" and then: :wq Obtain the leds-pca995x.c file in the next site: https://github.com/TechNexion/linux-tn-imx/blob/tn-imx_5.4.70_2.3.0-stable/drivers/leds/leds-pca995x.c Copy it into the next path: cp leds-pca995x.c ~/linux-imx/PCA9955 Obtain 0001-PCA9955BTW.patch file and copy it into the next path: cp 0001-PCA9955BTW.patch ~/linux-imx/PCA9955 Apply the patch. patch < 0001-PCA9955BTW.patch Then setup your toolchain, for example: source /opt/fsl-imx-wayland/5.10-hardknott/environment-setup-cortexa53-crypto-poky-linux Generate .ko file. cd ~/linux-imx/PCA9955 make all Copy the .ko file to the EVK, for example with scp: scp leds-pca995x.ko root@192.168.100.105:/home/root NOTE: The linux version of .ko file must be the same as EVK. On the EVK. Switching the device tree.   To copy the updated device tree to the corresponding partition, first create a directory. mkdir Partition_1 Mount the partition one. mount /dev/mmcblk1p1 Partition_1/ Copy or move the device tree into partition one. cp imx8mm-evk-8mic-revE.dtb Partition_1/ Reboot the board. reboot Stop on u-boot and modify the .dtb file to use the device tree for 8mic board. u-boot=> editenv fdtfile edit: imx8mm-evk-8mic-revE.dtb u-boot=> saveenv Saving Environment to MMC... Writing to MMC(1)... OK u-boot=> boot Installing a led driver.   Execute the following command to load the led driver into the kernel. insmod leds-pca995x.ko And you will see something like: [ 249.359103] leds_pca995x: loading out-of-tree module taints kernel. [ 249.366864] ALL [ 249.368740] ALL 0 [ 249.370667] ALL 1 [ 249.372609] ALL 2 [ 249.374536] ALL 2 [ 249.376475] ALL 2 [ 249.378401] ALL 2 [ 249.380338] ALL 2 [ 249.382264] ALL 2 [ 249.384202] ALL 2 [ 249.386127] ALL 2 [ 249.388063] ALL 2 [ 249.389989] ALL 2 [ 249.391913] ALL 2 [ 249.393847] ALL 2 [ 249.395774] ALL 2 [ 249.397709] ALL 2 [ 249.399635] ALL 2 [ 249.401568] ALL 2 [ 249.403496] ALL 3 Turning on a Led.   If you changed the device tree, you can turn on a led with the following command: echo 250 > /sys/class/leds/pca995x\:blue0/brightness To turn off a led: echo 0 > /sys/class/leds/pca995x\:blue0/brightness The red, blue and green leds can be turned on at different intensities provided. Testing the push buttons.   If you changed the device tree, you can test the push buttons with the following command: evtest Select the correct number: No device specified, trying to scan all of /dev/input/event* Available devices: /dev/input/event0: 30370000.snvs:snvs-powerkey /dev/input/event1: sw_keys /dev/input/event2: gpio_ir_recv Select the device event number [0-2]: 1 And you will see: Input driver version is 1.0.1 Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100 Input device name: "sw_keys" Supported events: Event type 0 (EV_SYN) Event type 1 (EV_KEY) Event code 67 (KEY_F9) Event code 113 (KEY_MUTE) Event code 114 (KEY_VOLUMEDOWN) Event code 115 (KEY_VOLUMEUP) Properties: Testing ... (interrupt to exit) Event: time 1642457988.1642457988, type 1 (EV_KEY), code 114 (KEY_VOLUMEDOWN), value 1 Event: time 1642457988.1642457988, -------------- SYN_REPORT ------------ Event: time 1642457988.1642457988, type 1 (EV_KEY), code 114 (KEY_VOLUMEDOWN), value 0 Event: time 1642457988.1642457988, -------------- SYN_REPORT ------------

What is Automotive Grade Linux? Automotive Grade Linux is a collaborative, open source project that brings together automakers, suppliers, and technology companies for the purpose of building Linux-based, open source software platforms for automotive applications that can serve as de facto industry standards. AGL address all software in the vehicle: infotainment, instrument cluster, heads-up-display (HUD), telematics, connected car, advanced driver assistance systems (ADAS), functional safety, and autonomous driving. Architecture The Automotive Grade Linux Software Architecture diagram is below. The architecture consists of five layers. The App/HMI layer contains applications with their associated business logic and HMI. The Application Framework layer provides the APIs for creating both managing and running applications on an AGL system. The Services layer contains user space services that all applications can access. The Operating System (OS) layer provides the Linux kernel and device drivers along with standard OS utilities. For IVI (In Vehicle Infotainment) system a full fledged demo is available. Supported Boards The following table briefs about the various hardware platforms, supported by AGL : BOARD $MACHINE ARCHITECHTURE BeagleBone bbe arm32   beaglebone arm32       i.MX 6 cubox-i arm32   imx6qdlsabreauto arm32   nitrogen6x arm32       i.MX 8 imx8mqevk arm64   imx8mqevk-viv arm64       Snapdragon dragonboard-410c arm64   dragonboard-820c arm64       ARC HS hsdk ARC       virtio virtio-aarch64 arm64   AGL Components AGL includes some major components showing as follow: agl-compositor waltham-receiver_waltham-transmitter rba drm-leasemanager appfw cynagora. pyagl pipewire_wireplumber agl-compositor When the AGL project was started, weston was chosen as the compositor, which is the reference implementation of a Wayland compositor, while for window management functionality it relied on ivi-shell (In-Vehicle Infotainment) together with an extension, called wayland-ivi-exension.   Waltham protocol is a IPC library similar to Wayland, developed with networking in mind. It operates over TCP sockets, while the wayland protocol only works locally over a UNIX socket. It retains wayland-esque paradigm, making use of XMLs to describe the protocol, and it follows an object-oriented design with an asynchronous architecture. DRM Lease Manager The DRM Lease Manager is used in AGL to allocate display controller outputs to different processes. Each process has direct access to its allocated output via the kernel DRM interface, and is prevented from accessing any other outputs managed by the display controller. PyAGL  PyAGL was written to be used as a testing framework replacing the Lua afb-test one, however the modules are written in a way that could be used as standalone utilities to query and evaluate apis and verbs from the App Framework Binder services in AGL. PipeWire / WirePlumber AGL uses the PipeWire daemon service to provide audio playback and capture capabilities. PipeWire is accompanied by a secondary service, WirePlumber (also referred to as the session manager), which provides policy management, device discovery, configuration and more. Applications can connect to the PipeWire service through its UNIX socket, by using either the libpipewire or libwireplumber libraries as a front-end to that socket. How to port AGL in i.MX8qm get agl source as follow: repo init -b koi -uhttps://git.automotivelinux.org/AGL/AGL-repo repo sync apply patches in attachment add file agl_imx8qmmek.inc to path 'meta-agl\meta-agl-bsp\conf\include'. add files 40_bblayers.conf.inc, 50_local.conf.inc and 50_setup.sh to path 'meta-agl\templates\machine\imx8qmmek'. build as follow: source meta-agl/scripts/aglsetup.sh -f -m imx8qmmek agl-demo bitbake agl-demo-platform Then the wic image can be flashed into i.mx8qm showing as below:

    Test environment: MPU6050 module,i.MX8MP,Android11_2.4.0 This solution ported the MPU6050 module on Android to realize auto rotation of screen.      

This is a quick article focused on how to add the support of SFTP on the i.MX devices using Yocto to add that packages.   Refer to the pdf attached.

This is a quick article focused on how to add the support of the ssh on the i.MX devices using Yocto to add that packages.   Refer to the pdf attached.

This document describes the steps to create your own out-of-tree kernel module recipe for Yocto.

  1.overwrite the sources/meta-freescale/recipes-security/optee-imx with optee-imx.zip 2.add below code to conf/local.conf DISTRO_FEATURES_append += " systemd" DISTRO_FEATURES_BACKFILL_CONSIDERED += "sysvinit" VIRTUAL-RUNTIME_init_manager = "systemd" VIRTUAL-RUNTIME_initscripts = "systemd-compat-units" MACHINE_FEATURES_append += "optee" DISTRO_FEATURES_append += "optee" IMAGE_INSTALL_append += "optee-test optee-os optee-client optee-examples" 3.bitbake optee-examples or bitbake imx-image-xxx You can directly install optee-examples_3.11.0-r0_arm64.deb in your device.  

Symptoms   When configure a gpio pin for a driver in the dts/dtsi file like below example,   e.g.   a-switch {            compatible = "a-switch-driver";            pinctrl-names = "default";            pinctrl-0 = <&pinctrl_switch>;            gpios = <&lsio_gpio1 1 GPIO_ACTIVE_HIGH>;            status = "okay"; };   pinctrl_switch: switch_gpio {     fsl,pins = < IMX8QXP_SPI2_SDO_LSIO_GPIO1_IO01    0x21 >; };   then you may get the error when request the gpio in the driver during the kernel boot up.   Error message like this: a-switch: failed to request gpio a-switch: probe of a-switch failed with error -22   Linux version: L5.4.x   Diagnosis   Because the gpio_mxc_init function run before the function imx_scu_driver_init. The pm_domains for gpio is not ready before running mxc_gpio_probe, so gpio request will be failed.     Solution   There are two ways to resolve this issue 1. Build the driver as a module. i.e. select the driver in kernel’s menuconfig as “M”. Then , run “insmod” to load the driver after the kernel boot up.   OR   2. Apply below patch, let gpio driver init after scu driver. diff --git a/drivers/gpio/gpio-mxc.c b/drivers/gpio/gpio-mxc.c index 1dfe513f8fcf..52b5799040b3 100644 --- a/drivers/gpio/gpio-mxc.c +++ b/drivers/gpio/gpio-mxc.c @@ -892,7 +892,7 @@ static int __init gpio_mxc_init(void) return platform_driver_register(&mxc_gpio_driver); } -subsys_initcall(gpio_mxc_init); +device_initcall(gpio_mxc_init);  

1 - Introduction: The Ultra Secured Digital Host Controller (uSDHC) provides the interface between the host processor and the SD/SDIO/MMC cards. Most recent versions provides the ability to automatically select a quantized delay (in fractions of the clock period) regardless of on-chip variations such as process, voltage, and temperature (PVT). The auto tuning is performed during runtime at hardware level, no software enablement is needed to drive this feature. 2 - Failure description: SDIO cards can implement an optional feature that uses DATA[1] to signal the card's interrupt to the i.MX device, this feature can be enabled by the SDIO card device and does not depends on i.MX uSDHC driver configuration. NXP Linux BSP is enabling the auto tuning for high SDIO frequencies (SDR104 and SDR50). Out of reset uSDHC_VEND_SPEC2 register is configured to use DATA[3:0] for calibration, this setup can conflict with the SDIO interrupt as DATA[1] signal can be asserted asynchronously. SDIO failures can be observed when running SDIO applications that requires high usage of the SDIO interface (e.g Download of large files), SDIO controller cannot return an accurate DLL causing failures such as "CMD53 read error". Failure can be observed on i.MX8MM EVK and i.MX8MN EVK boards, both devices are running 88w8987 Wi-Fi chipset at 208Mhz (SDR104). Users can observe an SDIO crash followed by error message below at Linux Kernel level. [ 401.945627] cmd53 read error=-84 [ 401.974677] moal_read_data_sync: read registers failed 3 - Impacted devices: The following devices are impacted by this limitation. - i.MX6 Family:   i.MX6SL, i.MX6SLL, i.MX6SX, i.MX6UL, i.MX6ULZ and i.MX6ULL. - All i.MX7 and i.MX7ULP family:   i.MX7D, i.MX7S and i.MX7ULP. - All i.MX8M Family:   i.MX8MQuad, i.MX8M Mini, i.MX8M Nano, i.MX8M Nano UL and i.MX8M Plus. - All i.MX8/8X Family:   i.MX8DQXP, i.MX8DX and i.MX8QM. NXP Linux BSP is enabling the auto tuning for SDR104 and SDR50 modes. Other operation modes are not impacted by this limitation. Users can poll uSDHCx_CLK_TUNE_CTRL_STATUS register when running SDIO applications to confirm. TAP_SEL_PRE field is updated automatically during run time and constant variations can point to an incorrect delay cell calculated by the uSDHC controller.   All NXP Wi-Fi chipsets are enabling SDIO interrupt during firmware load, failures can be observed with any Wi-Fi vendor enabling SDIO asynchronous interrupt. 4 - Software changes: Recommendation is to enable auto tuning for DATA[0] and CMD signals only, DATA[1] should not be used for auto calibration to avoid a possible conflict with SDIO interrupt. This setup can only be used if SDIO interface length are well matched. Software patches can be found at codeaurora.org. Fix is already included in L5.10.52-2.1.0 BSP, users can add fsl,sdio-interrupt-enabled property to uSDHC device tree node to enable SW workaround. https://source.codeaurora.org/external/imx/linux-imx/commit/?h=lf-5.10.y&id=3b3d6dec05277f7786d813592a31ea4a1ce60a74 https://source.codeaurora.org/external/imx/linux-imx/commit/?h=lf-5.10.y&id=b9b5a43df1d709809b2b654ad8f8181b00a4ee55 https://source.codeaurora.org/external/imx/linux-imx/commit/?h=lf-5.10.y&id=95a846af9f82dc6ea60064d9d12d5d2378e23941  

This note show how to use the open source gstreamer1.0-rtsp-server package on i.MX6QDS and i.MX8x to stream video files and camera using RTP protocol.  The i.MX 6ULL and i.MX 7 doesn't have Video Processing Unit (VPU). Real Time protocol is a very common network protocol for delivering media over IP networks. On the board, you will need a GStreamer pipeline that encodes the raw video, adds the RTP payload, and sends over a network sink. A generic pipeline would look as follows: video source ! video encoder ! RTP payload ! network sink Video source: often it is a camera, but it can be a video from a file or a test pattern, for example. Video encoder: a video encoder as H.264, H.265, VP8, JPEG and others. RTP payload: an RTP payload that matches the video encoder. Network sink: a video sync that streams over the network, often via UDP.   Prerequisites: MX6x o MX8x board with the L5.10.35 BSP installed. A host PC with either Gstreamer or VLC player installed. Receiving h.264/h.265 Encoded RTP Video Stream on a Host Machine Using GStreamer GStreamer is a low-latency method for receiving RTP video. On your host machine, install Gstreamer and send the following command: $ gst-launch-1.0 -v udpsrc port=5000 caps = "application/x-rtp, media=(string)video, clock-rate=(int)90000, encoding-name=(string)H264, payload=(int)96" ! rtph264depay ! decodebin ! videoconvert ! autovideosink sync=false   Using Host PC: VLC Player Optionally, you can use VLC player to receive RTP video on a PC. First, in your PC, create a sdp file with the following content:  stream.sdpv=0m=video 5000 RTP/AVP 96c=IN IP4 127.0.0.1a=rtpmap:96 H264/90000 After this, with the GStreamer pipepline on the device running, open this .sdp file with VLC Player on the host PC. Sending h.264 and h.265 Encoded RTP Video Stream GStreamer provides an h.264 encoding element by software named x264enc. Use this plugin if your board does not support h.264 encoding by hardware or if you want to use the same pipeline on different modules. Note that the video performance will be lower compared with the plugins with encoding accelerated by hardware. # gst-launch-1.0 videotestsrc ! videoconvert ! x264enc ! rtph264pay config-interval=1 pt=96 ! udpsink host=<host-machine-ip> port=5000 Note: Replace <host-machine-ip> by the IP of the host machine. In all examples you can replace videotestsrc by v4l2src element to collect a stream from a camera   i.MX8X # gst-launch-1.0 videotestsrc ! videoconvert ! v4l2h264enc ! rtph264pay config-interval=1 pt=96 ! udpsink host=<host-machine-ip> port=5000   i.MX 8M Mini Quad/ 8M Plus # gst-launch-1.0 videotestsrc ! videoconvert ! vpuenc_h264 ! rtph264pay config-interval=1 pt=96 ! udpsink host=<host-machine-ip> port=5000 i.MX6X The i.MX6QDS does not support h.265 so the h.264 can work: # gst-launch-1.0 videotestsrc ! videoconvert ! vpuenc_h264 ! rtph264pay config-interval=1 pt=96 ! udpsink host=<host-machine-ip> port=5000   Using Other Video Encoders While examples of streaming video with other encoders are not provided, you may try it yourself. Use the gst-inspect tool to find available encoders and RTP payloaders on the board: # gst-inspect-1.0 | grep -e "encoder"# gst-inspect-1.0 | grep -e "rtp" -e " payloader" Then browse the results and replace the elements in the original pipelines. On the receiving end, you will have to use a corresponding payload. Inspect the payloader element to find the corresponding values. For example: # gst-inspect-1.0 rtph264pay   Install rtp in your yocto different form L5.10.35 BSP, to install gstreamer1.0-rtsp-server in any Yocto Project image, please follow the steps below: Enable meta-multimedia layer: Add the following on your build/conf/bblayers.conf: BBLAYERS += "$"${BSPDIR}/sources/meta-openembedded/meta-multimedia" Include gstreamer1.0-rtsp-server into the image: Add the following on your build/conf/local.conf: IMAGE_INSTALL_append += "gstreamer1.0-rtsp-server" Run bitbake and mount your sdcard. Copy the binaries: Access the gstreamer1.0-rtsp-server examples folder: $ cd /build/tmp/work/cortexa9hf-vfp-neon-poky-linux-gnueabi/gstreamer1.0-rtsp-server/$version/build/examples/.libs Copy the test-uri and test-launch to the rootfs /usr/bin folder. $ sudo cp test-uri test-launch /media/USER/ROOTFS_PATH/usr/bin Be sure that the IPs are correctly set: SERVER: => ifconfig eth0 $SERVERIP CLIENT: => ifconfig eth0 $CLIENTIP Video file example SERVER: => test-uri file:///home/root/video_file.mp4 CLIENT: => gst-launch-1.0 playbin uri=rtsp://$SERVERIP:8554/test You can try to improve the framerate performance using manual pipelines in the CLIENT with the rtspsrc plugin instead of playbin. Follow an example: => gst-launch-1.0 rtspsrc location=rtsp://$SERVERIP:8554/test caps = 'application/x-rtp'  ! queue max-size-buffers=0 ! rtpjitterbuffer latency=100 ! queue max-size-buffers=0 ! rtph264depay ! queue max-size-buffers=0 ! decodebin ! queue max-size-buffers=0 ! imxv4l2sink sync=false   Camera example SERVER: => test-launch "( imxv4l2src device=/dev/video0 ! capsfilter caps='video/x-raw, width=1280, height=720, framerate=30/1, mapping=/test' ! vpuenc_h264 ! rtph264pay name=pay0 pt=96 )" CLIENT: => gst-launch-1.0 rtspsrc location=rtsp://$SERVERIP:8554/test ! decodebin ! autovideosink sync=false The rtspsrc has two properties very useful for RTSP streaming: Latency: Useful for low-latency RTSP stream playback (default 200 ms); Buffer-mode: Used to control buffer mode. The slave mode is recommended for low-latency communications. Using these properties, the example below gets 29 FPS without a sync=false property in the sink plugin. The key achievement here is the fact that there is no dropped frame: => gst-launch-1.0 rtspsrc location=rtsp://$SERVERIP:8554/test latency=100 buffer-mode=slave ! queue max-size-buffers=0 ! rtph264depay ! vpudec ! imxv4l2sink      

In some cases, i.MX board connect to different module. It has very tiny changes, such as just one gpio different driver strength. We can build an entire new software to handle this requirement. Here we introduce another way, using u-boot to modify the device tree(dtb) at runtime.   Here is u-boot fdt command for  How to use gpio-hog demo https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/How-to-use-gpio-hog-demo/ta-p/1317709   run loadfdt fdt addr ${fdt_addr_r} fdt print /soc/bus/pinctrl/uart3grp fdt rm /soc/bus/pinctrl/uart3grp fdt print serial2 fdt set serial2 status disabled fdt print serial2 fdt print gpio4 fdt resize fdt mknode gpio4 gpio_hog_demo fdt set gpio4/gpio_hog_demo gpio-hog fdt set gpio4/gpio_hog_demo gpios <7 0> fdt set gpio4/gpio_hog_demo output-high fdt print gpio4 run mmcargs run loadimage booti ${loadaddr} - ${fdt_addr_r} root@imx8mmevk:~# cat /sys/kernel/debug/gpio gpiochip0: GPIOs 0-31, parent: platform/30200000.gpio, 30200000.gpio: gpio-5 ( |PCIe DIS ) out hi gpio-13 ( |ir-receiver ) in hi IRQ ACTIVE LOW gpio-15 ( |cd ) in hi IRQ ACTIVE LOW gpiochip1: GPIOs 32-63, parent: platform/30210000.gpio, 30210000.gpio: gpio-38 ( |? ) out hi gpio-42 ( |reset ) out lo ACTIVE LOW gpio-51 ( |regulator-usdhc2 ) out lo gpiochip2: GPIOs 64-95, parent: platform/30220000.gpio, 30220000.gpio: gpio-80 ( |status ) out hi gpiochip3: GPIOs 96-127, parent: platform/30230000.gpio, 30230000.gpio: gpio-117 ( |PCIe reset ) out hi gpiochip4: GPIOs 128-159, parent: platform/30240000.gpio, 30240000.gpio: gpio-135 ( |gpio_hog_demo ) out hi gpio-141 ( |spi1 CS0 ) out hi ACTIVE LOW gpio-149 ( |wlf,mute ) out hi ACTIVE LOW root@imx8mmevk:~# [ 33.758914] VSD_3V3: disabling dtc_utils-v1.6.1-win-x86_64.zip by msys2   

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

 

Application Note AN13872  Enabling SWUpdate on i.MX 6ULL, i.MX 8M Mini, and i.MX 93 is available on www.nxp.com    SWUpdate: Embedded Systems become more and more complex. Software for Embedded Systems have new features and fixes can be updated in a reliable way. Most of time, we need OTA(Over-The-Air) to upgrade the system. Like Android has its own update system. Linux also need an update system. SWUpdate project is thought to help to update an embedded system from a storage media or from network. However, it should be mainly considered as a framework, where further protocols or installers (in SWUpdate they are called handlers) can be easily added to the application. Mongoose daemon mode: Mongoose is a daemon mode of SWUpdate that provides a web server, web interface and web application. Mongoose is running on the target board(i.MX8MM EVK/i.MX8QXP MEK).Using Web browser to access it.   Suricatta daemon mode: Suricatta regularly polls a remote server for updates, downloads, and installs them. Thereafter, it reboots the system and reports the update status to the server. The screenshot is SWUpdate scuricatta working with hawkbit server.          

Purpose This is early communication to notify i.MX 8M Dual/8M QuadLite/8M Quad customers of a potential incorrect PCIe power supply configuration on certain NXP BSP Linux and Android versions. Description The PCIE_VPH power supply is selectable in software  between 1.8V and 3.3V. When the PCIE_VPH supply is configured to operate at 3.3V, the 1.8V internal regulator (disabled by default) must be enabled to prevent overstress conditions on the PCIe PHY. If the 1.8V internal regulator is left disabled when the PCIE_VPH supply is configured to operate at 3.3V, it could potentially impact the product lifetime of the device.   Impact •i.MX 8M Dual/8M QuadLite/8M Quad (other i.MX processors are not impacted) •Only Impacts Linux/Android kernel versions earlier than L5.4.70_2.3.2 or Linux 5.10.9_1.0.0 releases MITIGATION •When the PCIE_VPH supply is configured to operate at 3.3V users need to enable the internal regulator by setting the IOMUXC_GPR_GPR14 and IOMUXC_GPR_GPR16 registers - PCIE1_VREG_BYPASS and PCIE2_VREG_BYPASS bit to 0. •There are 3 software patches for each release. Software patch details in the Code Aurora Forum (CAF): •For L5.4.70_2.3.2 patch release, the git log references are: •MLK-25349-3 PCI: imx: clear vreg bypass when pcie vph voltage is 3v3 •MLK-25349-2 arm64: dts: imx8mq-evk: add one regulator used to power up pcie phy •MLK-25349-1 dt-bindings: imx6q-pcie: add one regulator used to power up pcie phy • •The L5.4.70_2.3.2, LF_5.10 Q2 and later BSP releases correctly configure and enable the internal regulator by setting the IOMUXC_GPR_GPR14 and IOMUXC_GPR_GPR16 registers The Patch MLK-25349 which correctly enables the internal regulator is already included in the L5.4.70_2.3.2 patch release and release versions after it. MITIGATION •The following branches of Linux/Android BSP releases contain the MLK-25349 patch. The patch is attached below for each respective release.   •Other branches which are not listed should try to apply the nearest Patch version patch. If a user encounters any conflicts in applying, they should back porting from below nearest patch release version below. imx_4.9.51_ga, imx_4.9.y_android_imx8m_ga_v2                           - Patch attached  imx_4.9.88_ga, imx_4.9.y_android_2.0.0_ga                                   - Patch attached  imx_4.14.y and imx_4.14.98_2.3.0, imx_4.14.98_2.3.0_android     - Patch attached  imx_4.19.y and imx_4.19.35_1.1.0, imx_4.19.35_1.1.0_android     - Patch attached  imx_5.4.y, imx_5.4.3_2.0.0, imx_5.4.3_2.0.0_android                     - Patch attached Documentation Change Description – 1 of 3 for Datasheet Updated Datasheets and Reference Manual will be published to nxp.com. Updated Hardware Design guide and Schematics have already been published on nxp.com.  Updated the descriptions of PCIE_VPH in the Datasheet Table 8, "Operating ranges"     Documentation Change Description – 2 of 3 for Reference Manual (RM) Updated the description of field 12 "PCIE1_VREG_BYPASS" in 8.2.4.15 GPR14 General Purpose Register (IOMUXC_GPR_GPR14)           Documentation Change Description – 3 of 3 for RM Updated the description of field 12 "PCIE2_VREG_BYPASS" in 8.2.4.17 GPR16 General Purpose Register (IOMUXC_GPR_GPR16)   REFERENCES •i.MX 8M Dual / 8M QuadLite / 8M Quad Product Lifetime Usage  •i.MX 8M Dual / 8M QuadLite / 8M Quad Applications Processors Data Sheet for Industrial Products •i.MX 8M Dual / 8M QuadLite / 8M Quad Applications Processors Data Sheet for Consumer Products •i.MX 8MDQLQ Hardware Developer’s Guide  •i.MX 8M Dual/8M QuadLite/8M Quad Applications Processors Reference Manual  

i.MX8DXL DDR3L EVK board, nor flash using is MT25QU512ABB8ESF-0SIT. This doc will show reference of FlexSPI configuration parameters to make booting from MT25Q flash, with QUAD pad and DDR mode. HW: i.MX8DXL DDR3L EVK board SW: Linux 5.4.70 BSP From RM 5.9.3.2 FlexSPI serial flash BOOT operation, the FlexSPI boot flow as :   FlexSPI configuration parameters,  could be think as two kind group: parameter for FlexSPI controller,  parameter related to the operation on nor flash.   Full parameter table check check i.MX8DXL RM Table 5-20. FlexSPI Configuration block. Let us check MT25Q data sheet for its feature, note our target is DDR mode(80MHZ) and QUAD pad:     Now let us change the FlexSPI configuration parameters: 1>readSampleClkSrc , set as 2 , that is loop back from SCK pad; this filed default set as 0, as found default value booting will met failure in this use case, so change to 2. 2>deviceModeCfgEnable set 1, deviceModeSeq.seqNum set 1 , deviceModeSeq. seqId set to 4; deviceModeArg set 0x5f. i.MX8DXL will send some cmd to flash to make MT25Q enter DDR mode and QUAD mode, so deviceModeCfgEnable =1. For seqNum=1, seqId =4; means index 4 of LUT table will store this sequence, and cost one LUT entry. We will explain how to change LUT entry later. For deviceModeArg=0x5f, check MT25Q data sheet, its enhanced volatile register could be write to configure the flash working mode:  3>controllerMiscOption as 0x40, this parameter only for FlexSPI controller itself, means as” External device works using DDR commands”. 4>deviceType=1(Serial Nor),  sflashPadType=4 (QUAD pad),  serialClkFreq=4(80MHZ CLK), these parameter also only for FlexSPI controller. 5>sflashA1Size fill actual size, in terms of bytes 6>LUT entry changes, check 8DXL RM Table 5-21: So LUT entry 0 is sequence for Read command, entry 1 is for Read Status sequence, entry 3 is for Write Enable sequence,  entry 15 is for Dummy command sequence. Other index LUT entry(for example 2,4,6,7,8,10,12,13,14) is could be used for store your sequence for some cmd your flash device neede. We store sequence of writing MT25Q enhance volatile register as LUT entry 4. Check 8DXL RM,  Figure 15-6. LUT and sequence structure:   Each LUT entry (sequence) will using 16 byte,  one sequence consists of up to 8 instructions, each instruction will using 16bit. Each instruction  format as opcode—num_pads—operand. Check RM 15.2.4.8 Programmable Sequence Engine, for supported instructions:   Actually the Write enable sequence is run first before the other sequence, as we will write Mt25Q volatile register, before that need issue Write enable sequence. Check MT25Q data sheet: For this sequence only need one instruction, that is 0x0406, at this time still using is SDR and one pad mode:  Opcode (CMD_SDR),  one pad (0), operand (6).   LUT entry 1, Read status sequence, it is READ STATUS REGISTER (05h) of MT25Q , check data sheet: It use two instructions: 0x0405: opcode(CMD_SDR), pad (one pad), operand (0x5, READ STATUS REGISTER) 0x2404: opcode(READ_SDR), pad (one pad), operand (0x4 , byte number)   LUT entry 4, that is for make MT25Q enter DDR mode and quad pad: From MT25Q data sheet: It will use two instructions, that is 0x0461: opcode (CMD_SDR),  one pad (0), operand (0x61 WRITE ENHANCED VOLATILE CONFIGURATION REGISTER) 0x2001: opcode (WRITE_SDR 08), one pad(0), operand (1 byte data size) The 0x5f will be send out as data.   Next check LUT entry read , at this time MT25Q had enter QUAD pad and DDR mode: LUT entry 0, Read sequence, it is fast read data from MT25Q, from data sheet: will use four instructions , that is : 86ED, opcode (CMD_DDR ), pad ( four pad), operand (0xEDh fast read) 8a18, opcode (RADDR_DDR), pad (four pad), operand (0x18 , three byte address) B210, opcode(DUMMY_ADDR), pad (four pad), operand(0x10, dummy cycle) A604, opcode (READ_DDR), pad (four pad) , operand (0x4, data byte)   Reference: 1.i.MX8DXL Reference Manual 2.MT25Q data sheet              

1.  Introduction 1.1.        Purpose This application note introduces a procedure of how to port AVB/TSN stack and run referring feature demos on i.MX8DXL board. This can help users who want to run AVB/TSN demos to quickly understand and customized their own codes. Since many of the standards are only for TSN switch/bridges and i.MX8DXL is design to be a TSN/AVB endpoint, the demos did not implement a full stack or full standards. They only demonstrated the basic end-to-end point (talker to listener) A/V streaming without bridge or switch. The software used for example in this documentation are based on the opensource such as gstreamer and alsa utils.   1.2.        Overview 1.2.1.     AVB/TSN AVB (Audio Video Bridging) is a common name for the set of technical standards which provide improved synchronization, low-latency, and reliability for switched ethernet network. AVB was initially developed by the IEEE Audio Video Bridging task group of the IEEE 802.1 standards committee. In November 2012, AVB group was renamed to TSN (Time-Sensitive Networking) task group to reflect the expanded scope of its work, which is to provide the specifications that will allow time-synchronized low latency streaming services through IEEE 802 networks. The referring standards shows as follows:     TSN protocol additions QoS components supported in HW TSN MAC + SW driver Managed Object components expose i/f to allow support of standardized network config protocols (local & remote) Transport API to allow other transport layer to use TSN QoS Stack extensions to map traffic priority to application task scheduling Real Time, gPTP based, Best Effort 1.2.2.     Demo introduction   The two streams are defined as below to grantee time sensitive (sub-microsecond synchronization), low latency and bandwidth on the ethernet: Stream A: SR class A, AVTP Audio Format, PCM 16-bit sample, 48 kHz, stereo, 12 frames per AVTPDU. Stream B: SR class B, AVTP Compressed Video Format, H.264 profile High, 1920x1080, 30 fps. The two TSN streams would be allocated into different TC (traffic control) class for egress. Different TC class would be mapped to different hardware queues with specific DMA channel which supported by ENET_OoS IP. The demos were built by follow blocks:   Linux Traffic Control: streams egress control Linux ptp: clock sync in network Libavtp: Time Sensitive Applications AV Transport protocol Gstreamer: avtp plugin uses the libavtp to transmit and receive AVTP audio/video (audio pcm, video h264).   1.2.3.     Traffic control Multiply queue qdiscs + CBS: The CBS class is actually handled by hardware IP to select which queue for transmitting.   CBS parameters come straight from the IEEE 802.1Q-2018 specification. They are the following: idleSlope: rate credits are accumulated when queue isn’t transmitting; sendSlope: rate credits are spent when queue is transmitting; hiCredit: maximum amount of credits the queue is allowed to have; loCredit: minimum amount of credits the queue is allowed to have;     2.  Build demo 2.1.        Build yocto $ DISTRO=fsl-imx-xwayland MACHINE=imx8dxlevk source imx-setup-release.sh -b ./xwayland $ bitbake imx-image-full Prepare a SD card and burn it with the built out images. 2.2.        Rebuild kernel Rebuild the kernel after applying the 0001-qenet-add-queue-avoid-panic.patch, and overwrite the Image and imx8dxl-evk.dtb on the boot partition of the SD card. 2.3.        Install the toolchain $ bitbake -f fsl-image-validation-imx -c populate_sdk $ sh tmp/deploy/sdk/fsl-imx-xwayland-glibc-x86_64-fsl-image-validation-imx-aarch64-imx8dxlevk-toolchain-5.4-zeus.sh The toolchain would be installed into /opt/fsl-imx-xwayland/5.4-zeus   2.4.        Create a install folder $ mkdir <your install folder> Create a folder to install all of the shared libraries, binaries and configure files which built out manually in this doc. After built done, you should copy all of the contents in this folder to target board root.   2.5.        Build libavtp $ source /opt/fsl-imx-xwayland/5.4-zeus/environment-setup-aarch64-poky-linux $ git clone https://github.com/Avnu/libavtp.git $ cd libavtp $ meson build --prefix=<your install folder>/usr $ ninja -C build Copy the built out .so and .pc into the toolchain rootfs: $ sudo cp build/libavtp.so* /opt/fsl-imx-xwayland/5.4-zeus/sysroots/aarch64-poky-linux/usr/lib $ sudo cp build/meson-private/*.pc /opt/fsl-imx-xwayland/5.4-zeus/sysroots/aarch64-poky-linux/usr/lib/pkgconfig/ Copy the .so into the install folder: $ cp build/libavtp.so* <install folder>/usr/lib/ To make sure you have avtp package installed correctly:     $ pkg-config --list-all | grep avtp   2.6.        Build ALSA aaf plugin $ cd <yocto build>/tmp/work/aarch64-poky-linux/alsa-plugins/1.1.9-r0/alsa-plugins-1.1.9 $ ./configure --build=x86_64-linux --host=aarch64-poky-linux --target=aarch64-poky-linux --prefix=<install folder>/usr --disable-silent-rules --disable-dependency-tracking --with-libtool-sysroot=<yocto build>/xwayland/tmp/work/aarch64-poky-linux/alsa-plugins/1.1.9-r0/recipe-sysroot --disable-static --enable-aaf --disable-jack --disable-libav --disable-maemo-plugin --disable-maemo-resource-manager --enable-pulseaudio --enable-samplerate --with-speex=lib $ make $ make install   2.7.        Build Gstreamer AVTP plugins （1.17.x） 2.7.1.     Build Gstreamer core $ git clone https://gitlab.freedesktop.org/gstreamer/gstreamer.git $ patch -p1 < gstreamer-1.0-pass-build.patch $ meson build --prefix=<install folder>/usr $ ninja -C build $ sudo ninja -C build install After Gstreamer is installed into <your install folder>, please fix the “prefix” path in the .pc files by, and copy to the toolchain folders: $ cd <your install folder> $ grep -lR <your install folder> ./lib/pkgconfig/ | xargs sed -i 's/<your install folder>/\/usr/g' $ cp -rf ./usr/* /opt/fsl-imx-xwayland/5.4-zeus/sysroots/aarch64-poky-linux/usr/ 2.7.2.     Build gst-plugins-base $ git clone https://gitlab.freedesktop.org/gstreamer/gst-plugins-base.git $ cd gst-plugins-base $ patch -p1 < gst-plugins-base-pass-build.patch $ meson build --prefix=<your install folder>/usr $ ninja -C build $ sudo ninja -C build install   2.7.3.     Build gst-plugins-bad $ git clone https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad.git $ cd gst-plugins-bad $ meson build --prefix=<your install folder>/usr $ ninja -C build $ sudo ninja -C build install   After gst-plugins-base and gst-plugins-bad installed into <your install folder>, please fix the “prefix” path in the .pc files and copy them into the toolchain folders: $ cd <your install folder> $ grep -lR <your install folder> ./lib/pkgconfig/ | xargs sed -i 's/<your install folder>/\/usr/g' $ cp -rf ./usr/* /opt/fsl-imx-xwayland/5.4-zeus/sysroots/aarch64-poky-linux/usr/   2.8.        Build H.264 SW plugins 2.8.1.     Build x264 As the yocto actually has the x264 recipes, but not included in our bblayers, we need to copy the x264 source into our bblayers path under <yocto>/source to build: $ cp -rf ./poky/meta/recipes-multimedia/x264 ./meta-openembedded/meta-multimedia/recipes-multimedia/ $ vi ./meta-openembedded/meta-multimedia/recipes-multimedia/x264_git.bb Remove the LICENSE_FLAGS line $ bitbake -f x264 -c do_install $ sudo cp -rf tmp/work/aarch64-poky-linux/x264/r2917+gitAUTOINC+72db437770-r0/image/usr/* /opt/fsl-imx-xwayland/5.4-zeus/sysroots/aarch64-poky-linux/usr/ 2.8.2.     Build gst-plugins-ugly $ git clone https://gitlab.freedesktop.org/gstreamer/gst-plugins-ugly.git $ cd gst-plugins-ugly $ meson build --prefix=<your install folder>/usr $ ninja -C build $ sudo ninja -C build install   2.8.3.     Build libav $ cp -rf poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav meta-openembedded/meta-multimedia/recipes-multimedia/gstreamer-1.0/ Remove the LICENSE_FLAGS line $ vim ./poky/meta/recipes-multimedia/gstreamer/gstreamer1.0-libav_1.16.2.bb $ bitbake -f gstreamer1.0-libav -c do_install $ cp /opt/samba/nxf39444/imx-yocto-bsp-i.mx8dxl/xwayland/tmp/work/aarch64-poky-linux/gstreamer1.0-libav/1.16.2-r0/image/usr/lib/gstreamer-1.0/libgstlibav.so <your install folder>/usr/lib/gstreamer-1.0   2.8.4.     Install binaries Final step is to copy all of your built out files from <your install folder> into your board / root, and boot up the board. $ export GST_PLUGIN_PATH=/usr/lib/gstreamer-1.0/ $ gst-inspect-1.0 To check if the above Gstreamer plugins we built out can be found by gst-instpect.   3.  System Setup 3.1.        VLAN The ENTE_QoS is assigned to eth0 instance. So create eth0.5 for vlan id 5: $ ip link add link eth0 name eth0.5 type vlan id 5 egress-qos-map 2:2 3:3 $ ip link set eth0.5 up   3.2.        Qdiscs The TSN control plane is implemented through the TC (Traffic Control) system. The transmission algorithms specified in the FQTSS (Forwarding and Queuing for Time-Sensitive Streams) chapter of IEEE 802.1Q-2018 are supported via TC Qdiscs (Queuing Discipline). 3.2.1.     MQPRIO qdisc $ tc qdisc add dev eth0 parent root handle 100 mqprio num_tc 3 map 0 0 2 1 0 0 0 0 0 0 0 0 0 0 0 0 queues 1@0 1@1 1@2 hw 1 3.2.2.     CBS qdisc Q1 CBS for audio, Q2 CBS for video: $ tc qdisc replace dev eth0 parent 100:3 handle 888 cbs idleslope 3648 sendslope -996352 hicredit 12 locredit -113 offload 1 $ tc qdisc replace dev eth0 parent 100:2 handle 777 cbs idleslope 98688 sendslope -901312 hicredit 153 locredit -1389 offload 1 3.2.3.     TimeSync Run the ptp4l and phc2sys in background, and use check_clocks to check the ptp sync works. $ ptp4l -i eth0 -f ./gPTP.cfg --step_threshold=1 & $ pmc -u -b 0 -t 1 "SET GRANDMASTER_SETTINGS_NP clockClass 248 clockAccuracy 0xfe offsetScaledLogVariance 0xffff currentUtcOffset 37 leap61 0 leap59 0 currentUtcOffsetValid 1 ptpTimescale 1 timeTraceable 1 frequencyTraceable 0 timeSource 0xa0" $ ./check_clocks -d eth0 4.  Run demo 4.1.        ALSA AAF audio To run the alsa AAF demo, please add aaf0 and converter0 plugin device into /etc/asound.conf: pcm.aaf0 {    type aaf    ifname eth0.5    addr 01:AA:AA:AA:AA:AA    prio 2    streamid AA:BB:CC:DD:EE:FF:000B    mtt 50000    time_uncertainty 1000    frames_per_pdu 12    ptime_tolerance 100 } pcm.converter0 {    type linear    slave {                  pcm "hw:0,0"                  format S16_LE    } } The “aaf0” plugin device defines the ethernet interface which AAF runs on, the socket priority which mapping to Traffic Class in kernel TC, the stream-id for the aaf streaming. The “converter0” plugin device is used for convert the S16_BE format to S16_LE for the wm8960 PCM audio.   Select one device as AVB talker, and run: $ speaker-test -p 25000 -F S16_BE -c 2 -r 48000 -D aaf0   Select one device as AVB listener, and run: $ arecord -F 25000 -t raw -f S16_BE -c 2 -r 48000 -D aaf0 | aplay -F 25000 -t raw -f S16_BE -c 2 -r 48000 -D converter0   You can hear the sound on the listener device.   You can also check which qdisc queue is used for AAF by: $ tc -s qdisc   4.2.        Gstreamer AAF audio Select one device as AVB talker, and run: $ gst-launch-1.0 clockselect. \( clock-id=realtime audiotestsrc samplesperbuffer=12 is-live=true ! audio/x-raw,format=S16BE,channels=2,rate=48000 ! avtpaafpay mtt=50000000 tu=1000000 streamid=0xAABBCCDDEEFF000B processing-deadline=0 ! avtpsink ifname=eth0.5 address=06:98:c0:22:df:35 priority=3 processing-deadline=0 \)   Select one device as AVB listener, and run: $ gst-launch-1.0 clockselect. \( clock-id=realtime avtpsrc ifname=eth0.5 ! avtpaafdepay streamid=0xAABBCCDDEEFF000B ! queue max-size-bytes=0 max-size-buffers=0 max-size-time=0 ! audioconvert ! audioresample !  alsasink device="hw:0,0" \)   5.  Packet sniffer Use tcpdump on board to dump the L2 ethernet packet: $ tcpdump -i eth0 ether proto 0x22f0 -w dump.pcap The AVTP ether protocol code is 0x22f0 embedded inside the ether frame, or you can use "vlan 5" VLAN id for tcpdump parameters to dump. Then open this dump.pcap in the windows/Linux PC by the wireshark tool, it will automatically show the protocol inside the package, it can also parser the IEEE1722 (AVTP) CVF/AFF package header as below:   To measure the package latency from transmit port (talker) to receive port (listener), you can use the tcpdump on both end-points. And compare the Epoch Time the packet dumped: "Epoch Time: 1596252905.688243000 seconds". The delta of the epoch time of the same packet is around 100us~500us. This latency actually includes the AF_PACKET clone cost in kernel netfilter, also the tcpdump application schedule latency.   6.  Revision history summarizes the changes done to this document since the initial release. Table2. Revision history Revision number Date Substantive changes 1 5/2021 Initial release    

   

Compiling kernel module qca9377 in new bsp L5.10.9 has lots of errors.This is because lots of kernel apis has been dropped or changed from kernel5.4 to kernel5.10.But kernel module QCA9377 still using old api.So i fixed this compile errors and attach this patch.