1) rtsp gst-launch-1.0 rtspsrc location=rtsp://192.168.0.105:10000 name=source ! queue ! rtph264depay ! vpudec ! overlaysink source. ! queue ! rtpmp4gdepay ! aacparse ! beepdec ! alsasink pc side: open vlc, choose media , then choose stream and rtsp, then choose the port to 10000 2)udp imx side: gstream 0.1 version: gst-launch udpsrc do-timestamp=false uri=udp://192.168.0.255:10000 caps="video/mpegts" ! aiurdemux streaming_latency=400 name=d d. ! queue ! vpudec low-latency=true ! queue ! mfw_v4lsink sync=true d. ! queue ! beepdec ! alsasink sync=true gstream 1.0 version: gst-launch-1.0 udpsrc do-timestamp=false uri=udp://192.168.0.255:10000 caps="video/mpegts" ! aiurdemux streaming-latency=400 name=d d. ! queue ! vpudec ! queue ! overlaysink sync=true d. ! queue ! beepdec ! pulsesink sync=true pc side: open vlc , then choose media, then choose stream and add the ts file, then choose dup(legacy) in the destinationsetup, then set the same broadcasting address as the gstreamer command set, then streaming.

For early i.MX 8QuadXPlus MEK boards with C0 chips, power on the board when the board is connected to the PC with USB Type-C cable may cause the PC to shut down directly. This is a hardware known issue. another type of TCPC PHY chip will be used in later boards to fix this issue. If you have this kind of i.MX 8QuadXPlus MEK boards with c0 chips already, you can take below way to avoid this issue: 1. change the boot switch to "serial download mode", firstly power on the board, then connect the board to PC with Type-C cable. 2. download the attached files, uncompress this two files and put them in the same folder. 3. open the command window, change the working directory to the one contains the files just downloaded, and execute "uuu uuu_change_DRP_to_DFP.auto-imx8qxpc0mek" on command window. After the command being successfuley executed, the board can be powerwed up when the board is connected to PC with type-C cable.

Hi everyone, Can I stream video at some different resolutions at the same time using I.Mx6? Thank you.

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

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

 

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

Q: Some background; this instrument has one display connected to the LVDS output of the i.MX6Solo and the SVGA monitor is using the IPU port with an external Analog Devices ADV7125 DAC to actually drive the monitor (or projector).  From Tektronix: We got our kernel logo to show up on an external SVGA monitor as well as on the internal LVDS display so we now at least know that the hardware is functional. However, when our application starts running and writing to the fb0 (background) and fb1 (foreground/overlay) frame buffers, the external monitor (fb2 frame buffer) doesn't get updated. We need to know how to get the same data going to the external monitor as goes to the internal LVDS display.  the external monitor is 800x600 and the internal is 800x480 so we'd further like those 480 lines to show up centered in the 600 line monitor. We are also hoping that this can be down without having to write/DMA all of the data twice. The answer given is SR #1122663812 was "If the customer is using Linux, fb2 should also be drawed by their application."  This was considered in adequate and Tek replied: I would like to know if they are saying that the IPU absolutely cannot automatically do what we want and if not, why not?  I would like to have some detailed information to at least convince us that they've looked into this and it really isn't possible. A: In our Linux BSP we don't support such feature. And in android BSP it was already supported. The customer must draw the fb2 by their application, ipu doesn't have the feature that combining the fb0 and overlay fb1, then resize it to fb2 automatically. The customer application can drawing their UI into a memory, then use v4l2 output to draw this buffer to both fb0 and fb2, in this case, resizing will be implemented in V4l2 output driver with IPU hardware. And if the customer needs overlay on fb2, they must combine the two layer into memory with IPU task first, then using V4l2 output to render it to display fb2. For how to use IPU task, the customer can reference to BSP unit test code: imx-test-1.1.0\test\mxc_ipudev_test The summary: for dual display case, the fb0 and fb2 are just two framebuffer memory, they must be filled before rendering to display, on iMX6S/DL, only the fb0 has the hardware overlay (fb1); if the customer wants to show same contents on two displays in Linux, their application must draw the two framebuffers, but we had some hardware method to improve the performace, using GPU or IPU task. In Android, the application will not draw frame buffer directly, it will use Android surface flinger middleware to draw, so this feature was implemnted in surface flinger; but in Linux, there is no such middleware, and application draws the framebuffer directly, so the application should handle it. This document was generated from the following discussion: i.MX6Solo LDB/LVDS & LCD Ports Active Simultaneously

The attached document describes how to calculate ESAI Mclk Bitclk LRclk for imx6 sabreauto board based on 3.10.17 linux kernel.

All Boards Creating App MP3 OpenEmbedded

Detailed Features List of i.MX35 PDK board I.MX35 CPU Card Additional Resources I.MX35 PDK Board Flashing SD Card i.MX35 PDK Board Flashing NAND i.MX35 PDK Linux Booting SD Loading Redboot Binary Directly to RAM Fixing Redboot RAM Bug Fixing Redboot RAM bug (CSD1 not activated)

Question: The i.MX6 documentation gives several different values for the maximum frequency of the IPU’s HSP_CLK clock. What are the correct HSP_CLK maximum frequency values for the i.MX6 Dual/Quad and Solo/DualLite? Can HSP_CLK run at 270 MHz on both the DQ and SDL CPUs, but it’s not clear from the documentation if this is permitted. Maximum HSP_CLK frequencies listed in the reference manual (DQ😞 264 MHz (Table 9-2 (IPU IP Parametric Table), Table 9-5 (IPU Clock Sources)) 266 MHz (Table 18-3 (System Clock Frequency Values)) Maximum HSP_CLK frequencies listed in the reference manual (SDL😞 270 MHz (Table 9-2 (IPU IP Parametric Table), Table 9-5 (IPU Clock Sources), Table 18-3 (System Clock Frequency Values)) Answer: Referring to Figure 18-2, IPU1_HSP_CLK_ROOT may be selected to have 1 of 4 sources. These sources are highlighted in yellow on the northwest corner of the page and the previous paragraph states these are max values. Possible sources are 540, 528, 396, and 480 MHz. The 480 MHz is divided by 4 before the selector, so winds up being 120 MHz. Per the diagram, these are all divided by 2 for IPU1_HSP_CLK_ROOT. The result is 270, 264, 198, and 60 MHz choices. Therefore, the max for IPU1_HSP_CLK_ROOT is 270 MHz for DQ. MX6D/Q and MX6S/DL are different with respect to max HSP_CLK frequency. MX6D/Q = 264 MHz max MX6S/DL = 270 MHz max

Introduction Even though we have provided MQX OS support for imx6SX M4 core, we don’t need such complex operation system running on M4 core in some cases. For users who want to simplify and accelerate their M4 application development, bare metal codes without OS support is also a good choice. This demo will show how to develop bare metal codes for i.MX SoloX. Verified Platform imx6sx sabresd Application Notes How to develop bare metal codes running on M4 core .pdf Demo files a9_launch_m4: Run at A9 core and launch M4 core m4_apps: Run at M4 core

There developed the controller uses i.MX53 + Linux. Has developed a solution for building distributed information and control systems. Prototmpy been in operation for over a year. Examples: - Control Electromagnetic stirring (mixer) http://ontecom.com/en/catalog/ems / Rusal, Krasnoyarsk. - Moniroring and management of pumping stations. - Monitoring and control of climate control systems. You can create a smart home systems and iot. There is experience with PLC (Power Line Communication) Qualcomm/Atheros. In my spare time I develop a budget solution for PLC (Power Line Communication) control / monitoring components smart home. Based on the standard IEC 61131-3 developed software - distributed information management system. The solution is cross-platform. In a single system may be computers of different architectures and various operating systems. Such signals are synchronized controller ARM / Linux, and x86 server (Win, Linux, VMS, ...) Uses wxWidgets. Articles on this subject is, but in Russian.

i.MX6 4.0.0 BSP release doesn't support ASRC_P2P function. This patch provides the reference codes to enable ASRC_P2P function for SSI. It can convert input sample rate to 44.1K_16bit/44.1K_24bit and 48K_16bit/48K_24bit. You can modify the configurations in the Board file. By the way, the SSI controler works at slave mode. Known limitations for the patch: -- The SDMA doesn't support SSI Dual FIFO when using ASRC_P2P function. -- From the waveform, the converted 24bit data have some abnormal data(values between 0 and 1) , but can't hear any abnormal sound from headphone. One suggestion is given under https://community.freescale.com/docs/DOC-95340

 

share more detailed steps how to bring up stereo capture of basler camera by imx8mp

We have a ATK tool which can program image, also it can burn fuse for i.MX51. Since fuse is one time program, so please take care the fuse can't be turn back after programmed.

Building on the success of low-cost, high-performance application development kits, Freescale introduces the i.MX27 Lite Kit. Once again, Developed in Logic Product Development and Freescale have worked together to deliver a product-ready software and hardware platform for OEMs, ODMs, IDHs and independent developers and a price point that's quite appealing. The i.MX27 Lite Kit enables rapid design of embedded products targeting the medical, industrial, wireless, consumer markets and general purpose markets. Leverage the power of the i.MX27 multimedia processor in this cost-effective development solution. Features The Freescale i.MX27 SOM-LV is based on the i.MX27 multimedia applications processor running up to 400 MHz. Click here for the full list of i.MX27 SoC features: Includes i.MX27 SOM-LV module Standard peripheral connectors supporting: Ethernet, LCD, audio in/out, serial, CompactFlash®, MMC/SD, USB host, USB OTG, ATA LogicLoader™ (bootloader/monitor) in executable format GNU Cross-Development Toolchain (compiler, linker, assembler, debugger) included Kit contents: i.MX27 SOM-LV Application baseboard Expansion header breakout board Null-modem serial cable Ethernet crossover cable USB A to mini-B cable 5 volt power supply with power adapters (Europe, Japan, UK, and US) Logic Starter CD QuickStart Guide Zoom™ LV baseboard (146.1 x 158.8 x 17.1 mm) RoHS compliant

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.