On this tutorial we will review the implementation of Flutter on the i.MX8MP using the Linux Desktop Image. Please find more information about Flutter using the following link: Flutter: Option to create GUIs for Embedded System... - NXP Community Requirements: Evaluation Kit for the i.MX 8M Plus Applications Processor. (i.MX 8M Plus Evaluation Kit | NXP Semiconductors) NXP Desktop Image for i.MX 8M Plus (GitHub - nxp-imx/meta-nxp-desktop at lf-6.1.1-1.0.0-langdale) Note: This tutorial is based on the NXP Desktop Image Ubuntu 22.04 with Yocto version 6.1.1 – Langdale. Steps: 1. First, run commands to update packages. $ sudo apt update $ sudo apt upgrade 2. Install Flutter for Linux using the following command. $ sudo snap install flutter --classic 3. Run the command to verify the correct installation. $ flutter doctor With this command you will find information about the installation. The important part for our purpose is the parameter "Linux toolchain - develop for Linux desktop". 4. Run the command “flutter create .” to create a flutter project, this framework will create different folders and files used to develop the application.  $ cd Documents $ mkdir flutter_hello $ cd flutter_hello $ flutter create .​ 5. Finally, you can run the “hello world” application using: $ flutter run Verify the program behavior incrementing the number displayed on the window.  

One of the most popular use cases for embedded systems are projects destinated to show information and interact with users. These views are called GUI or Graphic User Interface which are designed to be intuitive, attractive, consistent, and clear. There are many tools that we can use to achieve great GUIs, mostly implemented for platforms such as Web, Android, and iOS. Here, we will need to introduce the concept of framework, basically, it is a set of tools and rules that provides a minimal structure to start with your development. Frameworks usually comes with configuration files, code snippets, files and folders organization helping us to save time and effort. Also, it is important to review the concept of SDK or Software Development Kit which is a set of tools that allows to build software for specific platforms. Usually supplies debugging tools, documentation, libraries, API’s, emulators, and sample code. Flutter is an open-source UI software development kit by Google that help us to create applications with great GUIs on different platforms from a single codebase. Depends on the reference, you can find Flutter defined as a framework or SDK and both are correct, however, an SDK could be a best definition thanks to Flutter supplies a wide and complete package to create an application in which framework is also included. This article is aimed at those that are in a prototyping stage looking for a different tool to develop projects. Also, this article pretends to be a theoretical introduction explaining the most important concepts. However, is a good practice to learn more about reviewing the official documentation from Flutter. (Flutter documentation | Flutter) Here is the structure used throughout this article: What is Flutter? Flutter details Platforms Programming language Official documentation Flutter for embedded systems What is Flutter? Flutter was officially released by Google in December 2018 with a main aim, to give developers a tool to create applications natively compiled for mobile (Android, iOS), web and desktop (Windows, Linux) from a single codebase. It means that as a developer, Flutter will create a structure with minimal code, configuration files, build files for each operating system, manifests, etc. in which we will add our custom code and finally build this code for our preferred OS. For example, we can create an application to review fruit and vegetable information and compile for Android and iOS with the same code. A basic Flutter development process based on my experience looks like the following diagram: Flutter has the following key features: Cross-platform development. Flutter allows the developer to create applications for different platforms using a single codebase. It means that you will not need to recreate the application for each platform you want to support.   Hot-reload. This feature allows the developer to see changes in real time without restarting the whole application, this results in time savings for your project.   High Performance Flutter apps achieve high performance due to the app code is compiled to native ARM code. With this tool no interpreters are involved.   UI Widgets Flutter supplies a set of widgets (UI components such as boxes, inputs text, buttons, etc.) predefined by UI systems guidelines Material on Android and Cupertino for iOS. Source: Material 3 Design Kit | Figma Community Source: Design - Apple Developer   Great community support. This feature could be subjective but, it is useful when we are developing our project find solutions to known issues or report new ones. Because of Flutter is an open source and is widely implemented in the industry this tool owns a big community, with events, forums, and documentation. Flutter Details Supported Platforms With Flutter you can create applications for: Android iOS Linux Debian Linux Ubuntu macOS web Chrome, Firefox, Safari, Edge Windows Supported deployment platforms | Flutter Programming Language Flutter use Dart, a programming language is an open-source language supported by Google optimized to use on the creation of user interfaces. Dart key features: Statically typed. This feature helps catching errors making the code robust ensuring that the variable’s value always match with the declared variable’s type. Null safety. All variables on Dart are non-nullable which means that every variable must have a non-null value avoiding errors at execution time. This feature also, make the code robust and secure. Async/Await. Dart is client-optimized which means that this language was specially created to ensure the best performance as a client application. Async/Await is a feature part of this optimization making easier to manage network requests and other asynchronous operations. Object oriented. Dart is an object-oriented language with classes and mixin. This is especially useful to use on Flutter with the usage of widgets. Compiler support of Just-In-Time (JIT) and Ahead-of-Time (AOT) JIT provides the support that enables the Hot Reload Flutter feature that I mentioned before. It is a complex mechanism, but Dart “detects” changes in your code and execute only these changes avoiding recompiling all the code. AOT compiler produces efficient ARM code improving start up time and performance. Official documentation Flutter has a rich community and documentation that goes from UI guidelines to an Architectural Overview. You can find the official documentation at the following links: Flutter Official Documentation: Flutter documentation | Flutter Flutter Community: Community (flutter.dev) Dart Official Documentation: Dart documentation | Dart Flutter for embedded systems So far, we know all the excellent features and platforms that Flutter can support. But, what about the embedded systems? On the official documentation we can find that Flutter may be used for embedded systems but in fact there is no an official supported platform. This SDK has been supported by their community, specially there is one repository on GitHub supported by Sony that provides documentation and Yocto recipes to support Flutter on embedded Linux. To understand the reason to differentiate between Flutter for Linux Desktop with official support and to create a specific Flutter support for embedded Linux is important to describe the basics of Flutter architecture. Based on the Flutter documentation the system is designed using layers that can be illustrated as follows:   Source: Flutter architectural overview | Flutter We can see as a top level “Framework” which is a high-level layer that includes widgets, tools and libraries that are in contact with developers. Below “Framework,” the layer “Engine” is responsible of drawing the widgets specified in the previous layer and provides the connection between high-level and low-level code. This layer is mostly written in C++ for this reason Flutter can achieve high performance running applications. Specifically for graphics rendering Flutter implements Impeller for iOS and Skia for the rest of platforms. The bottom layer is “Embedder” which is specific for each target and operating system this layer allows Flutter application to run as a native app providing the access to interact with different services managed by the operating systems such as input, rendering surfaces and accessibility. This layer for Linux Desktop uses GTK/GDK and X11 as backend that is highly dependent of unnecessary libraries and expensive for embedded systems which have constrained resources for computation and memory. The work around founded by Sony’s Flutter for Embedded Linux repository is to change this backend using a widely implemented backend for embedded systems Wayland. The following image illustrates the difference between Flutter for Linux Desktop and Flutter for Embedded Linux.   Source: What's the difference between Linux desktop and Embedded Linux · sony/flutter-embedded-linux Wiki · GitHub   Source: What's the difference between Linux desktop and Embedded Linux · sony/flutter-embedded-linux Wiki · GitHub Here is the link to the mentioned repository: GitHub - sony/flutter-elinux: Flutter tools for embedded Linux (eLinux) Finally, I would like to encourage you to read the official Flutter documentation and consider this tool as a great option compared to widely used tools on embedded devices such as Qt or Chromium. Also, please have a look to a great article written by Payam Zahedi delving into the implementation of Flutter for Embedded Linux measuring performance and giving conclusions about the usage of Flutter in embedded systems. (Flutter on Embedded Devices. Learn how to run Flutter on embedded… | by Payam Zahedi | Snapp Embedded | Medium).    

The i.MX 8QXP introduces a concept for manipulating resource allocation, power, clocking and IO configuration and muxing, the System Controller Unit (SCU) has been added to the system. The SCU is an Arm Cortex-M4 core and is the first processor to boot in the i.MX 8QXP design. It is the responsibility of the SCU to control: Boot management Power management Clock IO and reset management configuration and muxing Resource partitioning / access control DDR Management Temperature monitoring AP watchdog services Low power wakeup All those subsystems are abstracted thanks to the System Controller Firmware (SCFW) running in the SCU. Other software components communicate with SCU via an Application Programming Interface (API). This API makes Remote Procedure Calls (RPC) via an underlying Inter-Processor Communication (IPC) mechanism. Each OS distributed by NXP features a library that allows it to interact with the SCFW running on the SCU. The SCU sub-system is made out of: 1x Arm Cortex-M4 processor running at 266MHz with 256KB of Tightly Coupled Memory (TCM) It includes the following set of peripherals: 1x TPM 1x UART 1x I2C 8x GPIOs 4x MUs System Controller Firmware (SCFW) NXP only releases packages in a majority object code form, however a board.c file is provided in which most of the configuration of the SCFW can be done. The first main step from SCFW to configure the DDR and start all other cores in the system. The boot flow is described in the image below:   The i.MX8 boot sequence involves SCU ROM, SCFW, Security Controller (SECO) ROM, and SECO FW: At reset, the SCU ROM and SECO ROM both start execution The SCU ROM reads boot mode pins SCU ROM loads the first container from the boot media; this container always has the SECO FW, signed using the NXP key The SECO FW is loaded into SECO Tightly Coupled Memory (TCM) A message is sent by the SCU via private MU to the SECO ROM to authenticate and run SECO FW The SCU ROM loads the second container from the boot media; this container always has the SCFW and can be signed using the customer key SCFW is loaded to SCU TCM SCU ROM will then configure the DDR SCU ROM will start the SCFW From this point SCFW takes over and loads any image to the Arm Cortex-M or Cortex-A cores.   Downloading and building SCFW Download the Arm GCC toolchain from here: https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads Export the toolchain to compile SCFW: mkdir ~/gcc_toolchain cp ~/Downloads/gcc-arm-none-eabi-10.3-2021.10-linux.tar.bz2 ~/gcc_toolchain/ cd ~/gcc_toolchain/ tar -xvjf gcc-arm-none-eabi-10.3-2021.10-linux.tar.bz2 export TOOLS=~/gcc_toolchain/ Download the file IMX-SCFW-PORTING-KIT-1.4.2 from NXP. After the SCFW porting kit is downloaded and un-tar, navigate into packages and run the binary file inside: $ cd <download-dir>/packages/ $ chmod a+x imx-scfw-porting-kit-1.4.2.bin $ ./imx-scfw-porting-kit-1.4.2.bin Navigate inside the newly created “imx-scfw-porting-kit” and into “src”. Extract the desired SCFW porting kit. $ cd imx-scfw-porting-kit-1.4.2/ $ tar -xvf src/scfw_export_mx8qx.tar.gz $ cd scfw_export_mx8qx/ The tar file extracted will be different depending on which board is being used. All the code that is specific to a board configuration is under “platform/board/mx8qxp_mek/board.c” To compile SCFW type the following command: $ make qx B=mek R=B0 All the files resulting from compilation can be found inside build_mx8qx/

The default BSP is compiled based on the Yocto project, which is a streamlined production-level Linux BSP. However, for users who are accustomed to the Ubuntu environment, especially ROS users, the operation of Yocto will be relatively complicated. This article will introduce how to make an Ubuntu BSP for iMX8QM and demonstrate how to use ROS.   A complete Ubuntu BSP includes u-boot, Linux kernel and Ubuntu rootfs. We will use u-boot and Linux kernel in Yocto BSP official 6.1V BSP, and rootfs will still use ubuntu-base-18.04.4-base-arm64. The compilation method comes from the NXP forum. First download ubuntu-base-18.04.4-base-arm64.tar.gz from the link above, and then unzip it. $ mkdir ~/ubuntu-rootfs $ sudo tar vxf ubuntu-base-18.04.4-base-arm64.tar.gz -C ubuntu-rootfs Copy the script file and create ch-mount.sh. $ sudo chmod a+x ./ch-mount.sh The download above is a basic Ubuntu-base file system, which is missing many commonly used tools and requires us to install it. For this purpose, install the qemu-user-static software on your computer to simulate the arm64 operating environment. $ sudo apt install qemu-user-static Mount the Ubuntu-base file system and then operate directly in the arm64 environment. $ sudo ./ch-mount.sh -m ubuntu-rootfs/ Add a DNS server, such as 8.8.8.8, or other available DNS server IP. # echo nameserver 8.8.8.8 > /etc/resolv.conf Install relevant software, of course you can also add other software. # apt install language-pack-en-base sudo ssh net-tools \ network-manager iputils-ping rsyslog \ bash-completion htop resolvconf dialog \ vim nano v4l-utils alsa-utils git gcc \ less resolvconf autoconf autopoint libtool \ bison flex gtk-doc-tools glib-2.0 \ libglib2.0-dev libpango1.0-dev libatk1.0-dev kmod pciutils -y  Create a user and set a password, here the user name is ubuntu # useradd -s '/bin/bash' -m -G adm,sudo ubuntu # passwd ubuntu # passwd root # echo 'apalis-imx8' > /etc/hostname At this point basic Ubuntu has been configured. # exit $ sudo ./ch-mount.sh -u ubuntu-rootfs/  After the installation is complete, use the ubuntu user to log in to the debugging serial port, and the password is ubuntu. When starting for the first time after installation, it will wait for a long time due to initialization, and then enter the configuration interface including region, user settings, etc. Turn on Ethernet and set DNS server IP.  ubuntu@mx8QM:~$ sudo ifconfig eth0 up ubuntu@mx8QM:~$ sudo dhclient eth0 ubuntu@mx8QM:~$ sudo vi /etc/resolv.conf Start Weston: ubuntu@mx8QM:~$ export XDG_RUNTIME_DIR=/run/user/1000 ubuntu@mx8QM:~$ sudo -E weston --tty=1 & ubuntu@mx8QM:~$ weston-flower ROS test You can install ROS programs very conveniently in Ubuntu system. Please refer to the instructions below for details http://wiki.ros.org/melodic/Installation/Ubuntu http://wiki.ros.org/ROS/Tutorials ubuntu@mx8QM:~$ sudo apt install lsb-core ubuntu@mx8QM:~$ sudo sh -c 'echo "deb http://packages.ros.org/ros/ubuntu $(lsb_release -sc) main" > /etc/apt/sources.list.d/ros-latest.list' ubuntu@mx8QM:~$ sudo apt-key adv --keyserver 'hkp://keyserver.ubuntu.com:80' --recv-key C1CF6E31E6BADE8868B172B4F42ED6FBAB17C654 ubuntu@mx8QM:~$ sudo apt update ubuntu@mx8QM:~$ sudo apt install ros-melodic-desktop  Run the following commands on three SSH terminals to simulate communication between ROS nodes. ubuntu@mx8QM:~$ source /opt/ros/melodic/setup.sh ubuntu@mx8QM:~$ roscore ubuntu@mx8QM:~$ source /opt/ros/melodic/setup.sh ubuntu@mx8QM:~$ rosrun roscpp_tutorials talker ubuntu@mx8QM:~$ source /opt/ros/melodic/setup.sh ubuntu@mx8QM:~$ rosrun roscpp_tutorials listener Due to driver limitations, iMX8 does not support Xorg, so ROS's default graphical interface tools such as rqt cannot be used directly.        

1. MediaPlayer Architecture     MediaPlayer is the server, MediaPlayerService and MediaPlayerService :: Client is the client. MediaPlayerService realize the IMediaPlayerService, the main function is to create the right player through the url sent by MediaPlayer::setDataSource MediaPlayerService :: Client realize the IMediaPlayer, the main function is to call the player created by MediaPlayerService to do those specific start, stop, resume, pause…      Entering NuplayerDriver means entering Android MultiMedia Framework.   2. NuPlayer   The playback video is mainly completed through Nuplayer. The figure below includes parser, decoder and render.   NuPlayer::Source is the parser module. Its interface looks like a combination of MediaExtractor and MediaSource NuPlayer::Decoder connects to CCodec for decoding. CCodec has a state pattern and pass MediaBuffers around with messages. NuPlayer::Render is responsible for rendering audio and also controls when to post video buffers back to NativeWindow for A/V sync. 3. Decoding Framework 3.1 Framework of i.MX8MP, i.MX8MQ and i.MX8MM   Decoding Process between the framework, vendor decoder component and kernel as follows on i.MX8MP, i.MX8MQ and i.MX8MM.   3.2 Framework of i.MX8QM   Decoding Process between the framework, vendor decoder component and kernel as follows on i.MX8QM. stream on: start to decode/encode stream off: stop decoding/encoding qbuf:  Queue the v4l2buffer filled in the decoder into the buffer queue created in the vpu driver so that the VPU can obtain it for decoding. dqbuf: When the VPU decoding is completed, the buffer will be dequeueed so that the decoder/codec can continue to be used. 4. Decode Video and Display Process 4.1 i.MX8MM and i.MX8MP   For i.MX8MP and i.MX8MM, G2D is used to composite layers, and the buffer transmission is completed between Decoder and SurfaceFlinger through the BufferQueue mechanism. The process as follows:  BufferQueue: As the producer of BufferQueue, decoder provides the decoded buffer, and SurfaceFlinger, as the consumer of BufferQueue, composite the decoded video layer.  Display: Use G2D to composite Android layer and video layer on i.MX8MP. SurfaceFlinger will hand over all layers to Display HAL, and then composite them into the framebuffer by G2D. 4.2 i.MX8MQ   For i.MX8MQ, GPU3D is used to composite Android UI, DCSS is used to composite overlay and android UI. And the buffer transmission is completed between Decoder and SurfaceFlinger through the BufferQueue mechanism. The processing is as follows: BufferQueue: Decoder provides the decoded buffer as producer. SurfaceFlinger as the cosumer of BufferQueue.  Display: Using GPU3D to composite Android UI layers. And video layer will be submitted to DCSS (Display Controller) through Display HAL. DCSS:  Responsible for combining video overlay and Android UI for display. GLESRenderEngine: SurfaceFlinger calls the opengl interface through GLESRenderEngine to complete rendering composite. 4.3 i.MX8QM For i.MX8QM, GPU3D or DPU are used to composite. And the buffer transmission is completed between Decoder Filter Component and SurfaceFlinger through the BufferQueue mechanism. The processing as follows: Decoder Filter:  Because GPU3D cannot directly composite TILED type layers, it needs to be converted into Linear through Decoder Filter first, and then handed over to SurfaceFlinger. BufferQueue:  Decoder Fillter will receive the outputbuffer from Decoder. And Filter will be as producer of BufferQueue to provide the buffer. SurfaceFlinger will be as consumer of BufferQueue to consume the buffers. GLESRenderEngine: SurfaceFlinger calls the opengl interface through GLESRenderEngine to complete rendering composite. Note:  On i.MX8QM,  Not all situations are composited using the GPU3D. Please refer to the table below.   4.4 DRM Widevine (Secure Decoder)   Now we have enabled DRM Widevine on i.MX8MP/i.MX8MQ/i.MX8QM so that secure video can be played.  For i.MX8MP, Use OEMCrypto trusted applicaiton to decrypt the encrypted stream. And Use RDC/CSU to protected hardware for secure pipeline. The framework is as follows:   For i.MX8MQ, Use OEMCrypto trusted applicaiton to decrypt the encrypted stream. And Use RDC/CSU to protected hardware for secure pipeline. The framework is as follows:     OEMCrypto: It is a library as tipc client to send the encrypted data to Trusty OS. OEMCrypto Trusted Application: Used to decrypt the protected data into secure memory and send it to Media Framewrok. Secure Framebuffer: It is allocated from secure heap through libdmabufheap. Secure heap: Used to allocate secure memory.  Resources in domain2 can read and write secure memory, but cannot write normal memory. Resources in domain0 can write to secure memory, but cannot read normal memory. When playing secure video, VPU, GPU2D, and lcdif will be in domain2. Or they are in domain0. Resource Domain Controller (RDC): It provides support for the isolation of destination memory mapped locations such as peripherals and memory to a single core, a bus master, or set of cores and bus masters.  CSU Central Security Unit (CSU) : 1. Peripheral Access Policy - the appropriate bus master privilege and identity are required to access each peripheral. 2. Masters Privilege Policy - the CSU overrides the bus master privilege signals (secure/non-secure).  Configure the VPU so that it can only be accessed by the secure world. For i.MX8QM, also use OEMCrypto trusted applicaiton to decrypt the encrypted stream. But related hardware and memory are protected through the secure partition created by SCU. The framework is as follows: OEMCrypto: It is a library as tipc client to send the encrypted data to Trusty OS. OEMCrypto Trusted Application: Used to decrypt the protected data into secure memory and send it to Media Framewrok. Secure Framebuffer: It is allocated from secure heap through libdmabufheap. Secure heap: Used to allocate secure memory.  Only Secure partition can access secure memory. Frimware Loader: It is a trusted application in Trusty OS, It is responsible for loading the encrypted firmware into the specified memory. Secure Partition: Secure partitions are created using SCU and all hardware that needs to be protected are moved to secure partitions to isolate it from non-secure partitions. 5. Encoding Process 5.1 Encoding Process on i.MX8MP BufferQueue:  MediaFramework will create Surface and create BufferQueue, SurfaceFlinger will serve as the producer to provide the composite layers, and the Encoder component will encode it as the consumer of the BufferQueue. MPEG4Writer:  Responsible for writing the VPU-encoded data to the output file. 5.2 Encoding Process on i.MX8QM and i.MX8MM   BufferQueue:  MediaFramework will create Surface and create BufferQueue, SurfaceFlinger will serve as the producer to provide the composite layer, and the Encoder Filter component will be as the consumer of the BufferQueue. MPEG4Writer:  Responsible for writing the VPU-encoded data to the output file. 6. Buffer transfer and management 6.1 Transfer and release process of Input Buffer Input Buffer allocation: It is allocated in CCodecBufferChannel, and it is used to allocate inputbuffer and recycled. InputManager: Before the queue buffer into the decoder, it will be registered with the InputManager. When the VPU is finished using it, the InputManager will be notified to release it. Use of InputBuffer:  After the buffer is queued into the decoder, the input buffer information will be copied to v4l2buffer so that the VPU can use it. Note: For DRM Secure decoder, the VPU will only use the paddr of inputbuffer. 6.2 Transfer and release process of Output Buffer     Output Buffer allocation:  When use Surface for output, It is allocated through BufferQueueAllocator that is created in CCodecBufferChannel. It is used to allocate outputBuffer.  Management: When use Surface, OutputBuffer is managed through the BufferQueue mechanism. When the VPU filled the outputBuffer with data that can be displayed, it will notify the Consumer to acquire the buffer. Use of OutputBuffer: In the decoder, the output buffer information will be copied to v4l2buffer so that the VPU can use it. Note:  For situations where OutputSurface is not used, GrallocAllocator is used by default instead of BufferQueueAllocator. 6.3 Buffer Management of Encoder   For screen recording situations, the Encoder's buffer transfer is also managed through the BufferQueue mechanism. After SurfaceFlinger is producer to fill the GraphicBuffer of BufferQueue, the encoder is as consumer to encode the composited data.  

this article write down the steps when help customer bring dual camera under single mipi csi with NXP switch NX3DV642, just for a reference, connect OV5640 + os08a20 with mipi csi0 via ISP, as default, mipi csi0 just has one port with one camera, this document improve how to enable os08a20 with second port under mipi csi0, refer to the document and patch as attachment, for how to enable ov5640 with ISP, pls refer to my another document

This is a tool for screen capture under DRM (Direct Render Manager). This also a revised version for previous “drmfbcap” (DRM Framebuffer Capture). Unlike the FB based system under which we can capture the frame buffer easily through reading the device node, the DRM is much more complex and secure-protected. No direct way for reading framebuffer data from user space. Under DRM case, we need to open the DRM device, query the resource, get and map the FB object and then read the buffer eventually. With this tool, we can capture the buffer content from a DRM device and output as raw RGB/YUV data. Features: Capture all planes or specific plane, including hidden/covered planes or planes (overlays) managed by applications directly. Both RGB and YUV supported (auto detect). Tile format (VSI Super-Tile) is also supported. Repeat mode which can capture frames continuously. Tool was built as static linked, in this case, it should be working in both Linux and Android.   Important notes: Behavior of DRM subsystem is different between Linux 4.x and 5.x/6.x. For Linux 4.x, you can capture the RGB buffer without any problem. But, there’s no API for YUV (multi-plane) buffer. To capture YUV, please patch kernel with: “kernel_0001-drm-Add-getfb2-ioctl_L4.14.98.patch”. For Linux 5.x, mapping/capturing the internal buffer is not allowed by default due to security reason. To overcome this temporary (for debug only), patch the kernel with: “0001-drm-enable-mapping-of-internal-object-for-debugging_L5.x.patch”. It contains a minor change to remove this guard. Both patches are included in attachment. To get more details about how to use this tool, try “-h” option to print the usage message. Enjoy!

Customer is asking high-capacity external storage(for example >64GB) support on i.MX BSP, ext4 is ok for HC storage, but it can’t be supported by Windows. Pls find NFTS and exFAT support status on Linux BSP below: Updated test result on L5.4.70.2.3.0 and L6.1.22: L5.4.70.2.3.0 1.You can enable ntfs support in kernel config as below,  ntfs can be mounted normally, but you can only modify existing file content in disk, you can’t create/delete/rename file on disk. > File systems > DOS/FAT/NT Filesystems   Log: root@imx8mpevk:~# mount -t ntfs /dev/sda1 /mnt/fat/ [  662.732869] ntfs: volume version 3.1. root@imx8mpevk:~# cp ntfs-3g /mnt/fat/ cp: cannot create regular file '/mnt/fat/ntfs-3g': Permission denied root@imx8mpevk:~# ls /mnt/fat/ 111.png  Image_org  System Volume Information  gpuinfo.sh root@imx8mpevk:~# vi /mnt/fat/gpuinfo.sh root@imx8mpevk:~# umount /mnt/fat/ root@imx8mpevk:~# ntfs file system can be accessed via ntfs-3g in user space as below //build: wget https://tuxera.com/opensource/ntfs-3g_ntfsprogs-2017.3.23.tgz tar zxvf ntfs-3g_ntfsprogs-2017.3.23.tgz cd ntfs-3g_ntfsprogs-2017.3.23/ source ../../sdk/environment-setup-aarch64-poky-linux   ./configure --host=aarch64-linux --build=aarch64-poky-linux --disable-shared --enable-static   make   ls /src/ntfs-3g   //put it into rootfs cp ntfs-3g /bin   //test log: root@imx8mpevk:/# [ 1058.724471] usb 1-1: USB disconnect, device number 4 [ 1062.058613] usb 1-1: new high-speed USB device number 5 using xhci-hcd [ 1062.214029] usb-storage 1-1:1.0: USB Mass Storage device detected [ 1062.220986] scsi host0: usb-storage 1-1:1.0 [ 1063.235871] scsi 0:0:0:0: Direct-Access     VendorCo ProductCode      2.00 PQ: 0 ANSI: 4 [ 1063.246185] sd 0:0:0:0: [sda] 15728640 512-byte logical blocks: (8.05 GB/7.50 GiB) [ 1063.254023] sd 0:0:0:0: [sda] Write Protect is off [ 1063.259164] sd 0:0:0:0: [sda] No Caching mode page found [ 1063.264540] sd 0:0:0:0: [sda] Assuming drive cache: write through [ 1063.296946]  sda: sda1 [ 1063.300860] sd 0:0:0:0: [sda] Attached SCSI removable disk   root@imx8mpevk:/# ntfs-3g /dev/sda1 /mnt/fat/ root@imx8mpevk:/# ls /mnt/fat/ README  System Volume Information  gpu.sh  gpuinfo.sh root@imx8mpevk:/# cp /unit_tests/memtool /mnt/fat/ root@imx8mpevk:/# umount /mnt/fat/ root@imx8mpevk:/# ntfs-3g /dev/sda1 /mnt/fat/ root@imx8mpevk:/# ls /mnt/fat/ README  System Volume Information  gpu.sh  gpuinfo.sh  memtool root@imx8mpevk:/#   3.exFAT is not supported on this BSP..   L6.1.22(you can check it on L5.15 and above, should be the same) You can enable ntfs support in kernel config as below, full features can be supported. > File systems > DOS/FAT/EXFAT/NT Filesystems   Pls use ‘-t ntfs3’ during mounting, otherwise it will be mounted as ‘read-only’ Log: root@imx8ulpevk:~# mount -t ntfs3 /dev/sda1 /mnt/fat/ root@imx8ulpevk:~# ls /mnt/fat/ 111.png   Image_org  'System Volume Information' root@imx8ulpevk:~# root@imx8ulpevk:~# cp gpuinfo.sh /mnt/fat/ root@imx8ulpevk:~# umount /mnt/fat/ root@imx8ulpevk:~# root@imx8ulpevk:~# mount -t ntfs3 /dev/sda1 /mnt/fat/ root@imx8ulpevk:~# ls /mnt/fat/ 111.png   Image_org  'System Volume Information'   gpuinfo.sh root@imx8ulpevk:~#   exFAT has been supported in L6.1.22. > File systems > DOS/FAT/EXFAT/NT Filesystems   /dev/sda1 on /run/media/sda1 type exfat (rw,relatime,fmask=0022,dmask=0022,iocharset=utf8,errors=remount-ro) root@imx8ulpevk:~# ls /run/media/sda1 'Certificate of Completion.pdf'             carlife.MP4 Image_org                                  example.tflite L5.4.70_2.3.0                              mx8mp_vpu.txt NXP-5G.mp4                                 sd.mp4 'System Volume Information'                 vela.ini android_p9.0.0_2.1.0-auto-ga_image_8qmek root@imx8ulpevk:~# ls Image_org  gpuinfo.sh root@imx8ulpevk:~# cp gpuinfo.sh /run/media/sda1/ root@imx8ulpevk:~# umount /run/media/sda1 root@imx8ulpevk:~#

Hello everyone! In this quick example its focused on how to customize uboot code to generate an uboot image with a silent console so its speed up the flash and boot time, this may provide helpful for customers who have a bigger images or just want to have a silent console. Note: this should not be enabled if the image is still being under test, since this will disable all communication with the debug terminal and there won't be boot messages. Requirements: I.MX 8M Nano DDR4 EVK i.MX 8M Nano EVK Prebuilt image (6.1.1-1.0.0) UUU tool First clone the code from the uboot repository: $ git clone https://github.com/nxp-imx/uboot-imx -b lf-6.1.1-1.0.0 $ cd uboot-imx After we get the code, then proceed to enable the silent console in the uboot defconfig: $ nano configs/imx8mn_ddr4_evk_defconfig CONFIG_SILENT_CONSOLE=y CONFIG_SILENT_U_BOOT_ONLY=y For this to actually work we need to create the silent environmental variable and give it a value different from "0": $ nano include/configs/imx8mn_evk.h "silent=1\0"      \ As specified in our Linux porting guide: Generate an SDK from the Yocto Project build environment with the following command. To set up the Yocto Project build environment, follow the steps in the i.MX Yocto Project User's Guide (IMXLXYOCTOUG). In the following command, set Target-Machine to the machine you are building for. See Section "Build configurations" in the i.MX Yocto Project User's Guide (IMXLXYOCTOUG) Set up the host terminal window toolchain environment: $ source/opt/fsl-imx-xwayland/6.1.1/environment-setup-aarch64-poky-linux $ export ARCH=arm64 Build uboot binary: $ make distclean $ make imx8mn_ddr4_evk_defconfig $ make Build ARM Trusted Firmware (ATF) $ cd .. $ git clone https://github.com/nxp-imx/imx-atf -b lf-6.1.1-1.0.0 $ cd imx-atf/ $ make PLAT=imx8mn bl31 In case you get the error aarch64-poky-linux-ld.bfd: unrecognized option '-Wl,-O1' $ unset LDFLAGS Download the DDR training & HDMI binaries $ cd .. $ mkdir firmware-imx $ cd firmware-imx $ wget https://www.nxp.com/lgfiles/NMG/MAD/YOCTO/firmware-imx-8.19.bin $ chmod a+x firmware-imx-8.19.bin $ ./firmware-imx-8.19.bin Accept EULA and the firmware will be deployed. Download imx-mkimage and build the boot image $ cd .. $ git clone https://github.com/nxp-imx/imx-mkimage -b lf-6.1.1-1.0.0 $ cd imx-mkimage $ cp ../uboot-imx/spl/u-boot-spl.bin iMX8M/ $ cp ../uboot-imx/u-boot-nodtb.bin iMX8M/ $ cp ../uboot-imx/arch/arm/dts/imx8mn-ddr4-evk.dtb iMX8M/ $ cp ../imx-atf/build/imx8mn/release/bl31.bin iMX8M/ $ cp ../firmware-imx/firmware-imx-8.19/firmware/ddr/synopsys/ddr4_* iMX8M/ $ cp ../uboot-imx/tools/mkimage iMX8M/mkimage_uboot $ make SOC=iMX8MN flash_ddr4_evk After this we can download our uboot image to our board, we can either use the uboot image for boot or for flashing purpose only. We can compare the time it takes using UUU with a standard pre-built image uuu -V -b emmc_all imx-boot-imx8mn-ddr4-evk-sd.bin-flash_ddr4_evk imx-image-full-imx8mnevk.wic It takes 485.5 seconds using normal uboot with debug console enabled. uuu -V -b emmc_all flash.bin imx-image-full-imx8mnevk.wic It takes 477.5 seconds using silent uboot console. Even if the speed is not greatly improved (~8 seconds), in larger files it could help to speed up flashing, even if wants to have the console silent is a good option. Hope everyone finds this useful! For any question regarding this document, please create a community thread and tag me if needed. Saludos/Regards, Aldo.

In some cases, such as mass production or preparing a demo. We need u-boot environment stored in demo sdcard mirror image.  Here is a way: HW:  i.MX8MP evk SW:  LF_v5.15.52-2.1.0_images_IMX8MPEVK.zip The idea is to use fw_setenv to set the sdcard mirror as the operation on a real emmc/sdcard. Add test=ABCD in u-boot-initial-env for test purpose. And use fw_printenv to check and use hexdump to double confirm it. The uboot env is already written into sdcard mirror(imx-image-multimedia-imx8mpevk.wic). All those operations are on the host x86/x64 PC. ./fw_setenv -c fw_env.config -f u-boot-initial-env Environment WRONG, copy 0 Cannot read environment, using default ./fw_printenv -c fw_env.config Environment OK, copy 0 jh_root_dtb=imx8mp-evk-root.dtb loadbootscript=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${bsp_script}; mmc_boot=if mmc dev ${devnum}; then devtype=mmc; run scan_dev_for_boot_part; fi arch=arm baudrate=115200 ...... ...... ...... splashimage=0x50000000 test=ABCD usb_boot=usb start; if usb dev ${devnum}; then devtype=usb; run scan_dev_for_boot_part; fi vendor=freescale hexdump -s 0x400000 -n 2000 -C imx-image-multimedia-imx8mpevk.wic 00400000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| hexdump -s 0x400000 -n 10000 -C imx-image-multimedia-imx8mpevk.wic 00400000 5f a4 9b 97 20 6a 68 5f 72 6f 6f 74 5f 64 74 62 |_... jh_root_dtb| 00400010 3d 69 6d 78 38 6d 70 2d 65 76 6b 2d 72 6f 6f 74 |=imx8mp-evk-root| 00400020 2e 64 74 62 00 20 6c 6f 61 64 62 6f 6f 74 73 63 |.dtb. loadbootsc| 00400030 72 69 70 74 3d 66 61 74 6c 6f 61 64 20 6d 6d 63 |ript=fatload mmc| 00400040 20 24 7b 6d 6d 63 64 65 76 7d 3a 24 7b 6d 6d 63 | ${mmcdev}:${mmc| 00400050 70 61 72 74 7d 20 24 7b 6c 6f 61 64 61 64 64 72 |part} ${loadaddr| 00400060 7d 20 24 7b 62 73 70 5f 73 63 72 69 70 74 7d 3b |} ${bsp_script};| 00400070 00 20 6d 6d 63 5f 62 6f 6f 74 3d 69 66 20 6d 6d |. mmc_boot=if mm| ...... ...... ...... 00401390 76 3d 31 00 73 6f 63 3d 69 6d 78 38 6d 00 73 70 |v=1.soc=imx8m.sp| 004013a0 6c 61 73 68 69 6d 61 67 65 3d 30 78 35 30 30 30 |lashimage=0x5000| 004013b0 30 30 30 30 00 74 65 73 74 3d 41 42 43 44 00 75 |0000.test=ABCD.u| 004013c0 73 62 5f 62 6f 6f 74 3d 75 73 62 20 73 74 61 72 |sb_boot=usb star| 004013d0 74 3b 20 69 66 20 75 73 62 20 64 65 76 20 24 7b |t; if usb dev ${| 004013e0 64 65 76 6e 75 6d 7d 3b 20 74 68 65 6e 20 64 65 |devnum}; then de| flash the sdcard mirror into i.MX8MP evk board emmc to check uuu -b emmc_all imx-boot-imx8mp-lpddr4-evk-sd.bin-flash_evk imx-image-multimedia-imx8mpevk.wic  The first time boot, the enviroment is already there.  How to achieve that: a. fw_setenv/fw_printenv: https://github.com/sbabic/libubootenv.git Note: Please do not use uboot fw_setenv/fw_printenv Compile it on the host x86/x64 PC. It is used on host. b. u-boot-initial-env Under uboot, make u-boot-initial-env Note: Yocto deploys u-boot-initial-env by default c. fw_env.config  imx-image-multimedia-imx8mpevk.wic 0x400000 0x4000 0x400000 0x4000 are from uboot-imx\configs\imx8mp_evk_defconfig CONFIG_ENV_SIZE=0x4000 CONFIG_ENV_OFFSET=0x400000 Now, you can run  ./fw_setenv -c fw_env.config -f u-boot-initial-env

Environment BSP: L6.1.22_2.0.0​ Platform: i.MX93 Links:  https://github.com/NXP/swupdate-scripts https://github.com/nxp-imx-support/meta-swupdate-imx   The AN13872 provides us the swupdate yocto layer, swupdate-scripts and test steps, but there is still much to add. The purpose of this knowledge base is to provide customized advice. 1.How to port meta-swupdate-imx to any yocto version you want? As meta-swupdate-imx only provide kirkstone version, we can upgrade or degrade it based on this version. We will take L6.1.22_2.0.0​ porting steps as an example. 1.1 Download Yocto layer  cd imx-yocto-bsp/sources git clone https://github.com/sbabic/meta-swupdate.git -b mickledore git clone https://github.com/nxp-imx-support/meta-swupdate-imx.git 1.2 Modify  Yocto layer  imx-yocto-bsp/sources/meta-swupdate-imx/conf/layer.conf   You can find swupdate version in imx-yocto-bsp/sources/meta-swupdate/recipes-support/swupdate/ 1.3 Handle patches in meta-swupdate-imx/recipes-bsp/u-boot/files/ About patchs in sources/meta-swupdate-imx/recipes-bsp/u-boot/files/ and imx-yocto-bsp/sources/meta-swupdate-imx/recipes-support/swupdate/files/, you need use devtool to unpack uboot and swupdate into workspace and add changes manunally for development. CONFIG_ENV_OFFSET_REDUND=CONFIG_ENV_OFFSET+CONFIG_ENV_SIZE   sources/meta-swupdate-imx/recipes-bsp/u-boot/u-boot-imx_%.bbappend 2.How to flash base image? Use uuu or dd command, just like common imx-image-xxx 3.swupdate-scripts porting suggestions 3.1 Partition table You can modify partition table refer the size of images. For different soc, the first offset is different. If you are porting i.MX8MP based on iMX8MM, the offset should be 32K.   3.2 Some errors 3.2.1 This error indicates that you need enlarge size of rootfs. e2fsck 1.45.5 (07-Jan-2020) The filesystem size (according to the superblock) is 887599 blocks The physical size of the device is 768000 blocks Either the superblock or the partition table is likely to be corrupt! Abort<y>?    3.2.2 You need upgrade e2fsck verison. e2fsck 1.46.5 (30-Dec-2021) /home/nxf65025/imx-yocto-bsp/swupdate-scripts/base_image_assembling/slota/core-image-base-imx93-11x11-lpddr4x- evk.ext4 has unsupported feature(s): FEATURE_C12 e2fsck: Get a newer version of e2fsck! /home/nxf65025/imx-yocto-bsp/swupdate-scripts/base_image_assembling/slota/core-image-base-imx93-11x11-lpddr4x- evk.ext4: ********** WARNING: Filesystem still has errors ********** resize2fs 1.46.5 (30-Dec-2021) resize2fs: Filesystem has unsupported feature(s) (/home/nxf65025/imx-yocto-bsp/swupdate-scripts/base_image_ass  solution: wget https://mirrors.edge.kernel.org/pub/linux/kernel/people/tytso/e2fsprogs/v1.47.0/e2fsprogs-1.47.0.tar.xz tar -xf e2fsprogs-1.47.0.tar.xz cd e2fsprogs-1.47.0/ ./configure make -j16 sudo make install   3.2.3 mtools /home/nxf65025/imx-yocto-bsp/swupdate-scripts/base_image_assembling/../utils/utils.sh: line 58: mdir: command not found /home/nxf65025/imx-yocto-bsp/swupdate-scripts/base_image_assembling/../utils/utils.sh: line 66: mcopy: command not found /home/nxf65025/imx-yocto-bsp/swupdate-scripts/base_image_assembling/../utils/utils.sh: line 66: mcopy: command not found /home/nxf65025/imx-yocto-bsp/swupdate-scripts/base_image_assembling/../utils/utils.sh: line 68: mdir: command not found solution: sudo apt-get install mtools

We are pleased to announce that Config Tools for i.MX v14.0 are now available. Downloads & links To download the installer for all platforms, please login to our download site via:  https://www.nxp.com/design/designs/config-tools-for-i-mx-applications-processors:CONFIG-TOOLS-IMX Please refer to  Documentation  for installation and quick start guides. For further information about DDR config and validation, please go to this  blog post. Release Notes Full details on the release (features, known issues...) The product is based on Eclipse 2022-12 Open JDK 17 is updated. Batch processing on command line is supported. Support for SDK 2.14 in Project cloner and Detect toolchain project is added. Quick fix for errors allows setting the "Called by the default initialization function" flag when it would fix an error. Search functionality to Code Preview is added. TEE Export TEE registers via wizard or command line is available. Boot ROM hiding feature is supported. Tier mode for TRDC is supported. Domain ambivalence for RDC masters is added. Master-specific memory alias Validation for A28 bit of MPU region address is added. Memory map filters are aligned with Arm terminology. Status bar is united with other tools. Pins Labels defined for Expansion header pins can be set as identifiers of the routed pin. Expansion headers can be locked for editing. Expansion headers and boards are added to the HTML and CSV reports. Pins filtering is added into the expansion header pin routing dialogs. Columns from Routing Details can be added to the External User Signals view. New External User Signals can be created for all routed pins that are missing in the signals table. Clocks Support for the same frequencies settings from different source for internal clocks is added.

vpuwraper can fulfill VPU decoder/encoder, if customer’s user case is simple, for example they just need to encode yuv stream to H264, or decode H264 stream to yuv, There is no need to use gstreamer or V4L2 complex framework, you can use vpuwraper. Platform: i.MX8MP + L5.4.70.2.3.0 Build Procedure: mkdir vpu cd vpu git clone https://github.com/nxp-imx/imx-vpuwrap   cd imx-vpuwrap/ git tag -l   git switch -c rel_imx_5.4.70_2.3.0   source ../../.././5.4.70.2.3.0/sdk/environment-setup-aarch64-poky-linux   make -f Makefile_8mp   Test on i.MX8MP EVK board Pls find attached test log for decode and encode If busChromaU in YUV file is null, you will failed to encode it,pls apply patch vpuwraper patch for L5.4.70.2.3.0.patch to fix t If YUV file is interleave format, you need to add add interleave parameter : -interleave 1 ./test_enc_arm_elinux -i test.yuv -o aaa.h264 -f 2 -w 176 -h 96 -interleave 1   Thanks, Lambert

On customer design, they may need to fine tune LVDS driver strength for different case, for example, PCB impedance does not match, or the value of terminal resistor in panel side is lower or bigger. In IMX8MPRM.pdf, it has reg for this feature:         LVDS is constant current source, when voltage on terminal or panel side is lower than spec, you need to increase output current to get higher voltage to meet spec. otherwise ,you need to reduce it There is no detail description for these bits, pls refer to below: CC_ADJ = 000b => 3.5mA as default CC_ADJ = 001b => 3.5mA + 0.215mA x 1 CC_ADJ = 010b => 3.5mA + 0.215mA x 2 CC_ADJ = 011b => 3.5mA + 0.215mA x 4 CC_ADJ = 100b => 3.5mA - 0.215mA x 4 CC_ADJ = 101b => 3.5mA - 0.215mA x 3 CC_ADJ = 110b => 3.5mA - 0.215mA x 2 CC_ADJ = 111b => 3.5mA - 0.215mA x 1   Thanks, Lambert

  Solution           

  Platform: i.MX8MP EVK , L6.1.22-2.0.0 LT9211 is a chip that can realize the conversion of MIPI DSI signals to LVDS signals. This patch is based on this mainline driver:https://github.com/nxp-imx/linux-imx/blob/lf-6.1.y/drivers/gpu/drm/bridge/lontium-lt9211.c Keypoint Move lt9211_host_attach function to lt9211_attach to skip bridge attach error.  

  It is a Matter Demo setup guide to set up Matter OTBR on i.MX MPU Platfrom. i.MX 2023Q2 release is based on Matter v1.1  Current test solutions. i.MX6ULL + 88W8987(WiFi-BT combo Module) + K32W(OpenThread RCP module) i.MX8MM + 88W8987(WiFi-BT combo Module) + K32W(OpenThread RCP module) i.MX8MM + IW612-RD-EVK (WiFi-BT-Thread tri-radio single-chip module) i.MX93 + IW612 (WiFi-BT-Thread tri-radio single-chip module) Matter Zigbee Bridge  https://community.nxp.com/t5/i-MX-Processors-Knowledge-Base/Matter-Zigbee-Bridge-base-on-i-MX-MPU-and-K32W/ta-p/1675962   if use imx8mm_k32w_matter.sh or imx93_matter.sh to setup OTBR, you need modify "SSID" and " WIFI_PWD" in the script.    

Traditional non-matter devices cannot directly join the matter network. But Matter Bridge solves the problem. Matter bridge can join a Matter network as a Matter device and nonmatter devices need to be mapped to Matter network as a dynamic endpoint. In this way, other Matter devices can communicate with non-matter devices through dynamic endpoints. The Guide is a Matter Zigbee Bridge implement based on i.MX93 + K32W0.     Feature List • Matter over Ethernet • Matter over Wi-Fi • Register and Remove Zigbee Deivces • Connect Zigbee devices into Matter ecosystem seamlessly • Zigbee Devices o OnOff cluster o Temperature Sensor Cluster • Matter Actions o Start Zigbee Network o Zigbee Network Permit Join o Factory Reset • No limitation if migrating to other i.MX MPU like i.MX6ULL, i.MX8MP • OTBR and Zigbee bridge can be integrated into one single device

This demo for all(bootloader, device tree, Linux kernel, rootfs) in spi. It uses raw read(sf read)/raw write(sf write in uuu script) to achieve that. sf probe 0; sf read ${fdt_addr} 0x500000 0x100000; sf read ${loadaddr} 0x600000 0x1E00000; sf read ${initrd_addr} 0x2400000 0x600000; setenv bootargs console=${console},${baudrate} earlycon=${earlycon},${baudrate} rdinit=/linuxrc; booti ${loadaddr} ${initrd_addr} ${fdt_addr} |-- 0001-all-in-spi-demo-lf-5.10.72-2.2.0.patch --- patch for this demo |-- demo_binary | |-- flash.b0.bin --- b0 bootloader | |-- flash.bin --- c0 bootloader | |-- Image-imx8qxpc0mek.bin --- Linux kernel | |-- imx8qxp-mek.dtb --- device tree | |-- uramdisk_boot.rootfs.aarch64.img --- ram disk | |-- uuu.qspi.all.b0.uuu --- uuu script for b0 | `-- uuu.qspi.all.uuu --- uuu script for c0 `-- readme.txt --- this file # The spi layout used is: # - --------- -------------------------------------------- # | | flash.bin | env | dtb | Image |rootfs| # - --------------- -------------------------------------- # ^ ^ ^ ^ ^ ^ ^ # | | | | | | | # 0 4kiB 4MiB 5MiB 6MiB 36MiB 42MiB 0x1000 0x400000 0x500000 0x600000 0x2400000 Test: HW: i.MX8QXP MEK SW: lf-5.10.72-2.2.0 + 0001-all-in-spi-demo-lf-5.10.72-2.2.0.patch Test log: SF: Detected mt35xu512aba with page size 256 Bytes, erase size 128 KiB, total 64 MiB device 0 offset 0x500000, size 0x100000 SF: 1048576 bytes @ 0x500000 Read: OK device 0 offset 0x600000, size 0x1e00000 SF: 31457280 bytes @ 0x600000 Read: OK device 0 offset 0x2400000, size 0x600000 SF: 6291456 bytes @ 0x2400000 Read: OK [ 4.787552] imx6q-pcie 5f010000.pcie: unable to add pcie port. [ 4.797467] Freeing unused kernel memory: 2944K [ 4.807379] Run /linuxrc as init process Starting syslogd: OK Starting klogd: OK Running sysctl: OK Starting network: OK /bin/sh: can't access tty; job control turned off / #  

In this article, I will explain how to set up the iMX8M Plus to use the 4K Dart BCON Basler Camera module. Requirements: Evaluation Kit for the i.MX 8M Plus Applications Processor. (i.MX 8M Plus Evaluation Kit | NXP Semiconductors) Basler Camera for i.MX 8M Plus (4K dart BCON for MIPI camera module for i.MX 8M Plus | NXP Semiconductors). Embedded Linux for i.MX Applications Processors (Embedded Linux for i.MX Applications Processors | NXP Semiconductors) (For this example we will use BSP version Linux 5.15.71_2.2.0) Serial Console Emulator Basler Camera Specifications and Manuals: Basler Camera Specifications at this link: Embedded Vision Kits daA3840-30mc-IMX8MP-EVK - Embedded Vision Kits (baslerweb.com). Basler Manual to identify and setting up the hardware at this link: daA3840-30mc-IMX8MP-EVK | Basler Product Documentation (baslerweb.com) Basler Camera Module out-of-box with i.MX 8M Plus Applications Processor. (Video: Basler Camera Module out-of-box with i.MX 8M Plus Applications Processor | NXP Semiconductors) Steps After setting up the hardware we will need to turn on the iMX8M Plus and follow these steps: 1. Stop the boot process on Uboot by pressing any key. 2. Use the following command to list interfaces. => mmc list Output example => FSL_SDHC: 1 (SD) => FSL_SDHC: 2 The above command will show you the device number in this example for SD, the device number is 1. 3. Then use fatls <interface> <device[:partition]> [<directory>] fatls mmc 1:1 (Device 1 : Partition 1) With this command, we will be able to list device tree files. => fatls mmc 1:1 4. Select imx8mp-evk-basler.dtb or imx8mp-evk-dual-basler.dtb and use the command editenv fdtfile.  => editenv fdtfile Output example edit: imx8mp-evk-basler.dtb 5. In edit command line put the selected device tree (*.dtb). 6. Use saveenv command to save environment and continue with the boot process. 7. Using the terminal and go to /opt/imx8-isp/bin and execute the script run.sh. $ ./run.sh -c basler_1080p60 -lm 8. Use the command gst-device-monitor-1.0 to list devices. Here you will find the path to the camera device. $ gst-device-monitor-1.0 Output example Device found: name : VIV class : Video/Source caps : video/x-raw, format=YUY2, width=[ 176, 4096, 16 ], height=[ 144, 3072, 8 ], pixel-aspect-ratio=1/1, framerate={ (fraction)30/1, (fraction)29/1, (fraction)28/1, (fraction)27/1, (fraction)26/1, (fraction)25/1, (fraction)24/1, (fraction)23/1, (fraction)22/1, (fraction)21/1, (fraction)20/1, (fraction)19/1, (fraction)18/1, (fraction)17/1, (fraction)16/1, (fraction)15/1, (fraction)14/1, (fraction)13/1, (fraction)12/1, (fraction)11/1, (fraction)10/1, (fraction)9/1, (fraction)8/1, (fraction)7/1, (fraction)6/1, (fraction)5/1, (fraction)4/1, (fraction)3/1, (fraction)2/1, (fraction)1/1 } ... properties: udev-probed = true device.bus_path = platform-vvcam-video.0 sysfs.path = /sys/devices/platform/vvcam-video.0/video4linux/video2 device.subsystem = video4linux device.product.name = VIV device.capabilities = :capture: device.api = v4l2 device.path = /dev/video2 v4l2.device.driver = viv_v4l2_device v4l2.device.card = VIV v4l2.device.bus_info = platform:viv0 v4l2.device.version = 393473 (0x00060101) v4l2.device.capabilities = 2216693761 (0x84201001) v4l2.device.device_caps = 69206017 (0x04200001) gst-launch-1.0 v4l2src device=/dev/video2 ! ... 9. Finally, use gstreamer to verify proper operation. (With this gstreamer pipeline you will see a new window with the camera output. Then, just rotate the lens to acquire the correct focus) $ gst-launch-1.0 -v v4l2src device=/dev/video2 ! "video/x-raw,format=YUY2,width=1920,height=1080" ! queue ! imxvideoconvert_g2d ! waylandsink Basic description of Gstreamer Pipeline gst-launch-1.0 -v: The option -v enables the verbose mode to get detailed information of process. v4l2src device=/dev/video2: Select input device in this case the camera is on path /dev/video3. "video/x-raw,format=YUY2,width=1920,height=1080": Received format from camera. queue: This command is a buffer between camera recording process and the following image process, this command help us to interface two process and prevent blocking where each process has different speeds, in other words, when a process A is faster than process B. imxvideoconvert_g2d: This proprietary plugin uses hardware acceleration to perform rotation, scaling, and color space conversion on video frames. waylandsink : This command creates its own window and renders the decoded frames processed previously. 10. Result     I hope this article will be helpful. Best regards, Brian.