Hello everyone, this document will explain on how to create and run a custom script for UUU (Universal Update Utility) tool Requirements: I.MX 8M Mini EVK Linux Binary Demo Files - i.MX 8MMini EVK (L5.10.35) UUU Serial console emulator (tera term or putty) Text editor (Notepad++, nano, etc) UUU is a pretty flexible tool since it uses the Fastboot protocol through uboot to flash the desired images, this will make possible to create a custom script to add many uboot commands to customize further the boot settings. In this example I will create a custom script which will flash uboot and Linux rootfs and write a Cortex-M binary to the FAT partition of the eMMC. At the same time I’ll create and modify a set of environmental variables, this variables will have a set of uboot commands that will load to the TCM this same binary before the device starts booting into Linux.   Creating the script For this document I'll be using Notepad++ but any text editor may be used instead, since the scripts used by UUU are written in plain text. The very first line of the script must be the version number which will represent the minimum UUU version that UUU can parse this script. For this case that version is 1.2.39 After it, we will add all standard commands to flash uboot and filesystem into the eMMC. Note: This may be also copied from the uuu.auto script inside the Demo files. Please note that the UUU commands format is PROTOCOL: CMD, for this example we will be using mainly SDP and FB protocols which corresponds to the serial download protocol and Fastboot respectively. For a list of all supported UUU protocols and commands please refer to the UUU documentation here: https://github.com/NXPmicro/mfgtools/releases/download/uuu_1.4.165/UUU.pdf Now add the following commands to the script, this will download and write into eMMC FAT partition, which was created when flashing the .wic image, the Cortex-M binary.   FB: ucmd setenv fastboot_buffer ${loadaddr} FB: download -f hello_world_test.bin FB[-t 20000]: ucmd fatwrite mmc ${emmc_dev}:1 ${fastboot_buffer} hello_world_test.bin ${fastboot_bytes}   #fatwrite write file into a dos filesystem "<interface> <dev[:part]> <addr> <filename> [<bytes> [<offset>]] - write file 'filename' from the address 'addr' in RAM  to 'dev' on 'interface' Note: The Cortex-M binary was named as hello_world_test.bin, but any example name may be used. At this point, in the script we will be using only uboot commands as seen above, in this case was fatwrite. The script will look as following: If the script is run now uboot (imx-boot-imx8mmevk-sd.bin-flash_evk), rootfs (imx-image-multimedia-imx8mmevk.wic) will be flashed and the Cortex-M binary (hello_world_test.bin) written to the FAT partition of the eMMC. To add environmental variables to modify uboot boot settings, i.e. overwrite the dtb variable so the EVK will select the RPMSG dtb, this in case the Cortex-M example needs to be run at the same time as Cortex-A. FB: ucmd setenv fdtfile imx8mm-evk-rpmsg.dtb Next add to the UUU script the set of uboot commands in form of environmental variables that will load to the TCM the Cortex-M binary   FB: ucmd setenv loadm4image "fatload mmc ${emmc_dev}:1 0x48000000 hello_world_test.bin; cp.b 0x48000000 0x7e0000 0x20000" FB: ucmd setenv m4boot "run loadm4image; bootaux 0x48000000" Note: This can be changed to load it to different targets not only TCM, for example DRAM. Now for the set of environmental variable to run when uboot starts booting into Linux we may add it to the variable mmcboot. Also adding the command to save the environmental variables set so the settings persist after reboot, this by adding the following commands to the script:   FB: ucmd setenv mmcboot "run m4boot; $mmcboot" FB: ucmd saveenv The resulting script will be the following: Now just save the script and name it as you see fit, for this example the name will be custom_script.auto.   Running the script To run a UUU script is pretty simple, just make sure that the files used in the script are in the same folder as the script. Windows > .\uuu.exe  custom_script.auto Linux $ sudo ./uuu custom_script.auto   Wait till it finish, turn the board off, set it to boot from eMMC and turn it on, the EVK will boot into Linux automatically and will launch the Cortex-M core automatically. We may also, double check that the environmental variables were written correctly by stopping at uboot and using the printenv command For this test I have used the Prebuilt image which includes sample Cortex-M4 examples for the EVK   further flexibility UUU scripts can be customized even more, for example using macros, so the script can take input arguments so it may be possible to select the uboot, rootfs, Cortex-M binary and dtb to be used when booting, and to be used for other i.MX chips as well. The resulting script will be as following: Note: Here is assumed that the dtb file is already at the FAT partition, if not same procedure may be added as the Cortex-M binary. To run a script which expect to have input arguments is as follow: Windows > .\uuu.exe -b uuu_cortexM_loader.auto imx-boot-imx8mmevk-sd.bin-flash_evk imx-image-multimedia-imx8mmevk.wic hello_world_test.bin imx8mm-evk-rpmsg.dtb Linux $ sudo ./uuu -b uuu_cortexM_loader.auto imx-boot-imx8mmevk-sd.bin-flash_evk imx-image-multimedia-imx8mmevk.wic hello_world_test.bin imx8mm-evk-rpmsg.dtb Please find both UUU scripts attached and feel free to use them. Hope this helps everyone to better understand how this tool works and the capabilities it have.

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.

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

  From L5.4 BSP, the iMX8QM HDMI RX feature is removed from BSP, but it is added back in L5.10.52 2.1.0 BSP. The followed is the detail steps to use HDMI RX.   We need enable the followed kernel config to make hdmirx driver work:     CONFIG_IMX8_MEDIA_DEVICE=y     CONFIG_MHDP_HDMIRX=y apply the attached kernel patch. put hdmi firmware “hdmirxfw.bin” and “hdmitxfw.bin” to SD card’s FAT partition test command:     gst-launch-1.0 v4l2src device=/dev/video2 ! autovideosink   Note: To test the hdmi feature, the display should also use the HDMI TX. And in Uboot, to load the hdmirx firmware, we can run the followed commands first, then run the "boot" command:     run loadhdprx     hdprx load 0x9c800000     setenv fdt_file imx8qm-mek-hdmi-rx.dtb  

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

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);  

adv7180 is the 8 bits parallel CSI interface TVin to iMX8QXP validation board. Its weaving mode de-interlace can be supported on both iMX8QXP B0 and C0 chips, but blending mode de-interlace can only work on iMX8QXP C0 chips.   ISL79987 is the 4 virtual channel TVin chip which can input 4 CVBS cameras to iMX8QXP with MIPI CSI2 inteface, it can only work with iMX8QXP C0 chips. The iMX8QXP B0 chips have MIPI CSI2 virtual channel errata.   To test the capture to file: $ /unit_tests/V4L2/mx8_v4l2_cap_drm.out -cam 1 -num 300 -fmt YUYV -of   To test the preview on screen: $ killall weston $ /unit_tests/V4L2/mx8_v4l2_cap_drm.out -cam 1 -fmt RGBP -num 30000   Note: 1. For weaving mode de-interlace, when the ISI is doing de-interlace, it can't do CSC at the same time, so preview will get color issue, because the real output video is always YUYV format. 2. For blending mode de-interlace, it must use ISI0, so for ISL79987, only one camera can use blending mode, the other three cameras are still using weaving mode. The preview color is OK for such use case. 3. The patch is for L4.19.35 BSP.     2019-11-14 update: Add the test application "mx8_v4l2_cap_drm.tar.gz" to support YUYV render to display. Test command to render 4 weaving mode cameras:    ./mx8_v4l2_cap_drm.out -cam 0xF -fmt YUYV -num 30000     2020-04-29 update: Add "0006-isl7998x-fix-the-mipi_bps-overwrite-issue-from-set_f.patch", it fixed the issue that MIPI bps information in isl7998x_data->format.reserved[0] had been overwritten by isl7998x_set_fmt().   2021-06-11 update: Added the patches based on L5.4.70_2.3.0 GA BSP.

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      

 

Software environment: L5.4.47_2.2.0 Hardware i.MX8QXPC0 EVK board In the uuu script we can see the bootloader imx-boot-imx8qxpc0mek-sd.bin-flash is necessary. The default BSP build generate in the yocto project is with the spl, some customers are confused about the how to build the imx-boot-imx8qxpc0mek-sd.bin-flash. Here I give the manually compile way and generate it in yocto. In the yocto generate it is more convenient than the manually compile way. Hope this can do help for you.

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              

This doc share one OpenGL ES sample code, it is running on i.MX8 MEK board with QNX SDP7.1. HW: i.MX8 MEK board, HDMI display SW: QNX SDP7.1, i.MX8 MEK board BSP, and this sample code   This sample code will draw 3D object model, and with some animation. Reference: https://www.nxp.com/products/processors-and-microcontrollers/arm-processors/i-mx-applications-processors/i-mx-8-processors/i-mx-8-family-arm-cortex-a53-cortex-a72-virtualization-vision-3d-graphics-4k-video:i.MX8 https://github.com/NXPmicro/gtec-demo-framework https://github.com/syoyo/tinyobjloader-c https://github.com/nothings/stb https://3dhaupt.com/futuristic-car-game-ready-download/ https://wallpapersafari.com/w/Y5JZNh https://www.pngwing.com/en/free-png-ysaus https://www.shadertoy.com/view/Ms2SWW#

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] 

platform: imx8qxp c0 mek OS: yocto 4.19.35_1.1.0 hardware connection: imx8qxp lvds0 => dummy panel ,  lvds1 => it6263 => display   On imx8qxp there are one DPU(display process unit) and one ISI(image subsystem interface), ISI supports input from dpu.   dpu block diagram: note that only dsi0 and lvds0 can be used for loopback. and this patch only test the lvds0, since lvds support dummy panel.   Please see the readme in the attchment for how to enale this feature.   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]   

Default system can’t start Weston GUI in monitor after booting with NFS, so I find a solution to fix that issue. 1.Error messages imx8mpevk login: [31.274389] systemd[1]:weston@root.service: Main process exited, code=exited, status=1/FAILURE [ 31.274928] systemd[1]: weston@root.service: Failed with result 'exit-code'. [04:52:59.571] logind: not running in a systemd session [04:52:59.571] logind: cannot setup systemd-logind helper (-61), using legacy fallback 2.Steps Step 1:Add output in the /etc/xdg/weston/Weston.ini [output] name=HDMI-A-1 mode=1920x1080@60 Step 2:ls /sys/class/drm There will be some device nodes like card0,card1-HDMI-A-1. card1-HDMI-A-1 is we need. Step 3:Change drm_device in /etc/xdg/weston/Weston.ini drm-device=card1 Step 4:Set envs export WESTON_DRM_PRIMARY=HDMI-A-1 export WESTON_DRM_MIRROR=1 export WESTON_DRM_KEEP_RATIO=1 export WESTON_DRM_PREFER_EXTERNAL=1 export WESTON_DRM_PREFER_EXTERNAL_DUAL=1 Step 5:Start Weston weston --tty=7 -B=drm-backend.so --idle-time=0&

  Some customers are using sgtl5000 in android. So i generate this patch of sgtl5000 in Android11(i.MX8QM)

This document shows how to build genivi step by step, but I haven’t tested the images yet, before building the images, pls refer to the host setup and host packages according to the yocto project user’s guide, I don’t mention here again, this is for imx8mq as example, you can choose the different board name to build   Before building the genivi package, customer also can refer to the kernel and image name from: https://github.com/GENIVI/meta-ivi/tree/master   4.9.88 IMAGE   1. Create a bin folder in the home directory $ mkdir ~/bin (this step may not be needed if the bin folder already exists) $ curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo $ chmod a+x ~/bin/repo    2. Add the following line to the .bashrc file to ensure that the ~/bin folder is in your PATH variable. export PATH=~/bin:$PATH    3. Yocto Project Setup $ mkdir imx-yocto-bsp $ cd imx-yocto-bsp $ repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b imx-linux-rocko -m imx-4.9.88-2.0.0_genivi.xml $ repo sync   4.update Weston 3.0.0 to Weston 4.0.0 $ git clone https://git.yoctoproject.org/git/meta-freescale -b warrior   then replace the wayland directory in "imx-yocto-bsp/sources/meta-fsl-bsp-release/imx/meta-bsp/recipes-graphics/wayland" with the "meta-freescale/recipes-graphics/wayland" in cloned directory.   5.image build DISTRO=nxp-imx-genivi-wayland MACHINE=imx8mqevk source ./nxp-setup-genivi.sh -b genivi-wayland   $bitbake  pulsar-image    6.Error fix if you don’t update Weston, you should get the error message like The error shows required Weston >=4.0.0, but current bsp includes Weston version is 3.0.0, so you need to update the Weston to the 4.0.0 step by step $ git clone https://git.yoctoproject.org/git/meta-freescale -b warrior $ rm -rf ../sources/meta-fsl-bsp-release/imx/meta-bsp/recipes-graphics/wayland $ cp -r meta-freescale/recipes-graphics/wayland ../sources/meta-fsl-bsp-release/imx/meta-bsp/recipes-graphics/   $ bitbake -c cleansstate wayland-ivi-extension $ bitbake  wayland-ivi-extension $ bitbake  pulsar-image   4.14.95 IMAGE   1. Create a bin folder in the home directory $ mkdir ~/bin (this step may not be needed if the bin folder already exists) $ curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo $ chmod a+x ~/bin/repo   2. Add the following line to the .bashrc file to ensure that the ~/bin folder is in your PATH variable. export PATH=~/bin:$PATH   3.Yocto Project Setup $ mkdir imx-yocto-bsp $ cd imx-yocto-bsp $ repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b imx-linux-warrior -m imx-4.19.35-1.1.0_genivi.xml $ repo sync   4. change Weston 6.0.1 to Weston 5.0.0 $ git clone https://git.yoctoproject.org/git/meta-freescale -b zeus   then replace the wayland directory in "imx-yocto-bsp/sources/meta-fsl-bsp-release/imx/meta-bsp/recipes-graphics/wayland" with the "meta-freescale/recipes-graphics/wayland" in cloned directory.   5.image build $ DISTRO=fsl-imx-wayland MACHINE=imx8mqevk source fsl-setup-release.sh -b build-wayland   $ bitbake  meta-ivi-image    6.Error fix if you don’t change Weston, you should get the error message like so try to change the Weston to the 5.0.0 step by step $ git clone https://git.yoctoproject.org/git/meta-freescale -b zeus $ rm -rf ../sources/meta-fsl-bsp-release/imx/meta-bsp/recipes-graphics/wayland $ cp -r meta-freescale/recipes-graphics/wayland ../sources/meta-fsl-bsp-release/imx/meta-bsp/recipes-graphics   $ bitbake -c cleansstate weston $ bitbake  weston $ bitbake  meta-ivi-image     5.4.24 IMAGE   1. Create a bin folder in the home directory $ mkdir ~/bin (this step may not be needed if the bin folder already exists) $ curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo $ chmod a+x ~/bin/repo   2. Add the following line to the .bashrc file to ensure that the ~/bin folder is in your PATH variable. export PATH=~/bin:$PATH   3.Yocto Project Setup $ mkdir imx-yocto-bsp $ cd imx-yocto-bsp $ repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b imx-linux-zeus -m imx-5.4.24-2.1.0_genivi.xml $ repo sync   4. image build $ DISTRO=fsl-imx-wayland MACHINE=imx8mqevk source imx-setup-release.sh -b build-wayland   $ bitbake  meta-ivi-image    

Environment: openjdk-8 with L5.4.24-2.1.0 and GCC-9 1. Clone meta-java with dedicated branch name: git clone git://git.yoctoproject.org/meta-java -b zeus 2. Update .bb file for compile error in meta-java: diff --git a/recipes-core/icedtea/icedtea7-native.inc b/recipes-core/icedtea/icedtea7-native.inc index 8d0dc71..153a604 100644 --- a/recipes-core/icedtea/icedtea7-native.inc +++ b/recipes-core/icedtea/icedtea7-native.inc @@ -26,7 +26,7 @@ CXXFLAGS_append = " -fno-tree-dse" CXX_append = " -std=gnu++98" # WORKAROUND: ignore errors from new compilers -CFLAGS_append = " -Wno-error=stringop-overflow -Wno-error=return-type" +CFLAGS_append = " -Wno-error=stringop-overflow -Wno-error=return-type -Wno-error=format-overflow" inherit native java autotools pkgconfig inherit openjdk-build-helper 3. Add meta-java layer into bblayers.conf: BBLAYERS += "${BSPDIR}/sources/meta-java" 4. Edit the conf/local.conf to add openjdk variables # Possible provider: cacao-initial-native and jamvm-initial-native PREFERRED_PROVIDER_virtual/java-initial-native = "cacao-initial-native" # Possible provider: cacao-native and jamvm-native PREFERRED_PROVIDER_virtual/java-native = "jamvm-native" # Optional since there is only one provider for now PREFERRED_PROVIDER_virtual/javac-native = "ecj-bootstrap-native" PREFERRED_PROVIDER_java2-runtime = " openjdk-7-jre" IMAGE_INSTALL_append = " openjdk-7-jdk " diff --git a/recipes-core/openjdk/openjdk-8-common.inc b/recipes-core/openjdk/openjdk-8-common.inc index d8b30b8..ed03d60 100644 --- a/recipes-core/openjdk/openjdk-8-common.inc +++ b/recipes-core/openjdk/openjdk-8-common.inc @@ -181,5 +181,5 @@ FLAGS_GCC9 = "-fno-lifetime-dse -fno-delete-null-pointer-checks" BUILD_CFLAGS_append = " ${@openjdk_build_helper_get_build_cflags(d)}" BUILD_CXXFLAGS_append = " ${@openjdk_build_helper_get_build_cflags(d)}" # flags for -cross -TARGET_CFLAGS_append = " ${@openjdk_build_helper_get_target_cflags(d)}" +TARGET_CFLAGS_append = " ${@openjdk_build_helper_get_target_cflags(d)} -Wno-error=format-overflow" TARGET_CXXFLAGS_append = " ${@openjdk_build_helper_get_target_cflags(d)}" diff --git a/recipes-core/openjdk/openjdk-8-native.inc b/recipes-core/openjdk/openjdk-8-native.inc index 321a43d..97ff03f 100644 5. Switch the host GCC to gcc-8 and g++-8: sudo apt-get install gcc-8 g++-8 sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-8 --slave /usr/bin/g++ g++ /usr/bin/g++-8 --slave /usr/bin/gcov gcov /usr/bin/gcov-8 --slave /usr/bin/gcov-tool gcov-tool /usr/bin/gcov-tool-8 --slave /usr/bin/gcc-ar gcc-ar /usr/bin/gcc-ar-8 --slave /usr/bin/gcc-nm gcc-nm /usr/bin/gcc-nm-8 --slave /usr/bin/gcc-ranlib gcc-ranlib /usr/bin/gcc-ranlib-8 sudo update-alternatives --config gcc  6. And change the conf/local.conf from openjdk-7 -> openjdk-8: PREFERRED_PROVIDER_java2-runtime = " openjdk-8-jre" IMAGE_INSTALL_append = " openjdk-8 " 

Hello everyone, In this document I'll explain on how to build the UUU (Universal Update Utility) using windows 10 PC. This may be useful in case of adding custom commands to run during the flash using built-in scripts, be it for debugging, fuse blowing, etc. First we need to download and install Visual Studio community, for this guide I'll use community 2019, version it is available here: https://visualstudio.microsoft.com/thank-you-downloading-visual-studio/?sku=Community&rel=16 For workloads select Universal Windows Platform development.   When installing, make sure to select and install the Git for windows complement, at the top select Individual components, this will display a new list, scroll down to code tools and you will find Git for windows, check this box In case Visual Studio is already installed, you may open the installer again and chose modify, this will let you install the complement as well. After the installation is complete we may run the git commands on the power shell. Now open the windows power shell and type the following commands: git clone https://github.com/NXPmicro/mfgtools.git // clones the MFGTool (UUU) source code from the github cd mfgtools // enters the mfgtools folder we just cloned git submodule init // creates the local configuration file for the submodules git submodule update // set the submodules to the commit specified by the main repository. At this point we can edit the built in scripts to add our custom commands, for this guide I'll add the printenv uboot command at the end of the flashing process. For this I'll enter the folder mfgtools/uuu, and edit emmc_burn_all.lst with any text editor, i.e. Notepad ++, add the command FB: ucmd printenv.   Save and close the editor, it is possible to add most uboot commands like for example the fuse commands to burn eFuses. Then we can now build the tool, opening msvc/uuu-static-link.sln with Visual studio, select solution uuu-static-link.sln   And finally build the solution: The executable (uuu.exe) would be at the following path: mfgtools\msvc\x64\Debug   Finally we run the built in script we modified and check the results. Find attached both the powershell and uboot logs, I tested this using an i.MX8MN with L5.4.47_2.2.0, running the following command: ./uuu.exe -v -b emmc_all imx-boot-imx8mnevk-sd.bin-flash_evk imx-image-full-imx8mnevk.wic Hope this may found useful for anyone trying to achieve something similar.

In this doc will show how to use i.MX8QXP DPU do image warp.   SW: i.MX Linux BSP L5.4.24_2.1.0 bsp release and patch in this doc HW: i.MX8QXP MEK board, ov5640 camera, HDMI display   Introduction Image Warping is the process of digitally manipulating image data such that the image’s projection precisely matches a specific projection surface or shape.   i.MX8QXP DPU controller could do image warp work by its blit engine and display engine. I choose to enable blit engine’s fetchwarp9 unit to do warp work. Check i.MX8QXP RM, Blit Engine support Image Warp as: “Performs a re-sampling of the source image with any pattern. The sample point positions are read from a compressed coordinate buffer.” So you need prepare two input buffers, one buffer store original image data, the other buffer store resample point coordinate, DPU blit engine will read that two buffer by fetchwarp9 unit, then output result image buffer which contain warped image data. Note i.MX8QXP DPU blit engine fetchwarp9 unit, for the input original image buffer, support RGB and YUV 4:4:4 format. The resample point coordinate buffer contents is depend on what kind warp transformation in your use case; and for each resample point coordinate format check i.MX8QXP RM fecthwarp unit description as below. In this doc, using the 2xs12.4 format, each point x coordinate use (12+4) bit, same as y coordinate.   For DPU fetchwarp9 unit, to enable it work for image warp, check i.MX8QXP RM:   2.Patch notes and test code imx8-dpu-warp-kernel.diff contain the kernel side change for drm ioctl api permission and add vmap function of ion dma_buf_ops. libg2d.so contain the binary for adding warp feature. g2d.h is header file which add define for G2D_WARP and G2D_YUV4. imx8-ov5640-dpu-warp-render.c is a sample code which show how to call g2d lib to image warp, need open the G2D_WARP flag. And this code contain some example calculate the coordinate buffer of rotate, swirl, barrel distortion, affine transformation, perspective transformation, wave transformation. And this code will show read camera input frame then add warp process , then render warp image frame to display.   The test cmd usage as below, read 1080P frame from ov5640 camera, do warp then render warp image to drm plane. Note as dpu fetchwarp9 unit support YUV 4:4:4 input image frame, so below cmd need set parameter YUV4, which will ask ISI driver output YUV 4:4:4 image frame. imx8-ov5640-dpu-warp-render  -i /dev/video0 -f YUV4  -S 1920,1080  -M imx-drm -p 91:38 -F XB24  -b 6  -e g2d  -t 5         -i <video-node> set video node (default: /dev/video0)         -f <fourcc>     set input format using 4cc         -S <width,height>       set input resolution         -s <width,height>@<left,top>    set crop area         -M <drm-module> set DRM module         -o <connector_id>:<crtc_id>:<mode>      set a mode         -p <connector_id>:<crtc_id>     output to a plane         -F <fourcc>     set output format using 4cc         -t <warptype>   set 0 neutual 1 rotate 2 swirl 3 divisionmodel 4 affine 5 perpsptive 6 wave         -b buffer_count set number of buffers        3.Example original image:                     Reference: https://www.nxp.com/webapp/Download?colCode=IMX8DQXPRM https://www.nxp.com/webapp/Download?colCode=L5.4.24_2.1.0_MX8QXPC0&appType=license https://en.wikipedia.org/wiki/Image_geometry_correction https://lists.freedesktop.org/archives/dri-devel/2012-March/019778.html https://store.kde.org/p/1246558 https://github.com/ImageMagick/ImageMagick