Recently, I was asked about software/hardware floating point support on i.MX6. There are some great articles on the freescale community already but lacks of introduction. This document shares some basic knowledge on it. VFP is ARM's "Vector Floating Point" unit. SIMD operations can be better performed on several FPU extensions provided by ARM (NEON as in Cortex-A8 and Cortex-A9) [1]. To test if hardware floating support on freescale's toolchain, I used a simple application below: $ cat haha.c #include <stdio.h>; int main() {         float a = 0.3f, b=1.2f;         printf("%f\n", a * b);         return 0; } Compile it as below, and got the hardware floating point enabled. $ arm-linux-gcc -march=armv7-a -mfpu=neon -mfloat-abi=hard -o haha haha.c This can be checked by readelf. If Tag_ABI_VFP_args[2] shows VFP, it is hard floating. Otherwise, soft floating. $ arm-linux-readelf -A haha Attribute Section: aeabi File Attributes   Tag_CPU_name: "7-A"   Tag_CPU_arch: v7   Tag_CPU_arch_profile: Application   Tag_ARM_ISA_use: Yes   Tag_THUMB_ISA_use: Thumb-2   Tag_FP_arch: VFPv3   Tag_ABI_PCS_wchar_t: 4   Tag_ABI_FP_denormal: Needed   Tag_ABI_FP_exceptions: Needed   Tag_ABI_FP_number_model: IEEE 754   Tag_ABI_align_needed: 8-byte   Tag_ABI_align_preserved: 8-byte, except leaf SP   Tag_ABI_enum_size: int   Tag_ABI_HardFP_use: SP and DP   Tag_ABI_VFP_args: VFP registers   Tag_DIV_use: Not allowed Compared to the one by not specifying floating, compiler use soft floating by default, $ arm-linux-gcc -o haha_soft haha.c And readelf won't have Tag_ABI_VFP_args. $ arm-linux-readelf -A haha_soft Attribute Section: aeabi File Attributes   Tag_CPU_name: "ARM10TDMI"   Tag_CPU_arch: v5T   Tag_ARM_ISA_use: Yes   Tag_THUMB_ISA_use: Thumb-1   Tag_ABI_PCS_wchar_t: 4   Tag_ABI_FP_denormal: Needed   Tag_ABI_FP_exceptions: Needed   Tag_ABI_FP_number_model: IEEE 754   Tag_ABI_align8_needed: Yes   Tag_ABI_align8_preserved: Yes, except leaf SP   Tag_ABI_enum_size: int   Tag_unknown_44: 1 (0x1) [1]: https://wiki.debian.org/ArmHardFloatPort/VfpComparison [2]: For more detail on the Tag expression, check http://infocenter.arm.com/help/topic/com.arm.doc.ihi0045d/IHI0045D_ABI_addenda.pdf

Config Tool Introduction and Use From i.MX93 using the Config Tool for the DDR configure. The Config Tools for i.MX is a suite of evaluation and configuration tools that help users from initial evaluation to production software development. Config Tools for i.MX is an easy-to-use way to configure the pins and DDR of the i.MX processor devices. The software, in general, enables you to create, inspect, change, and modify any aspect of the pin configuration and muxing of the device. It also allows you to configure and validate DDR settings. 1 Download and install The link in website: https://www.nxp.com/design/design-center/software/i-mx-developer-resources:IMXSW_HOME   The Config Tools for i.MX is installed as a desktop tool which then loads additional device information through a network connection, but does otherwise not need internet connection. It does not require a project setup, as all the settings are stored in text and generated source files, which then can be easily stored in a version control system or exchanged with other users. Config Tool function For the Config Tool have two function, one is the Pins tool another is the DDR tool functions. 1.1 Pins tool The Pins Tool makes pin configuration easier and faster with an intuitive and easy user interface, which then generates normal C code that can then be used in any C and C++ application. The Pins Tool configures pin signals from multiplexing (muxing) to the electrical properties of pins, and it also creates Device Tree Snippets Include (.dtsi) files and reports in CSV format. Pins Tool Configuration of pin routing/muxing Managing different functions used for routing initialization Configuration of pin functional/electrical properties Generation of code for routing and functional/electrical properties 1.2 DDR Tool   The DDR tool provides two main functionalities: configuration and validation. The DDR configuration provides a user-friendly graphical interface to configure the DDR controller and the DDR PHY. It can be used for tweaking some of the configuration parameters when you want to use different memory modules than the ones received with the board or when you want to optimize the configuration. DDR validation provides different scenarios to verify the DDR performance, by downloading a test image to the processor’s internal RAM through a USB connection. The result is sent to the DDR tool via the UART. DDR validation can help verify DDR stability on the board in a non-OS environment.   DDR Tool The DDR tool is designed for: Configuration of DDR controllers Validation of DDR configuration Support for i.MX 8M and i.MX93 families Configuration: Simplified UI for device configuration Advanced board configuration options Stressing: Stress tests with overnight option Optimization: Sweep ODT configuration and optimization of Vref for DQ and CA Virtual Timing Signal Analysis (vTSA) support: RX and TX data eye, CA BUS signals margin and CA Eye test for LPDDR4 DRAM Generation of C code for U-boot SPL driver The DDR tool allows you to view and configure basic DDR attributes, such as memory type, frequency, number of channels and others and test the DDR configuration by a variety of tests. After you have specified the connection type, you can choose scenarios, tests to run in these scenarios, and view the test results, logs, and summary.         2 Install Download Config_Tools_for_i.MX_v16_x64.exe   Note: In our company PC we need to apply the Admin Manage:   Config Tools for i.MX is available offline (local)  Minimum system requirements One of the following graphical operating systems: – Microsoft Windows 10 (64-bit) – Ubuntu 22.04 LTS Note: Linux-hosted variants of tools are distributed on Linux as 64-bit binaries, which may not work on 32-bit systems. – Supported desktop environments: GNOME – Mac OS X (12.x) 4 GB RAM Display with resolution 1024 x 768 Internet connection for dynamic download from processor database Note: If the MacOS is set to Traditional Chinese, Config Tools for i.MX starts in English and not Chinese. This is intended. 2 The use of the Config tool Configuration of DDR controllers 2.1 Creating a new configuration create a configuration from the Start development wizard or by selecting File > New from the Menubar. If you start creating your development for any NXP board or kit, we recommended you start with example to create a configuration for a board or a kit. Such configuration contains board-specific settings. If you select a processor, the configuration will be empty. 2.2 Run the Config tool Open the Config tool, choose the Creating a new standalone configuration for a processor, board, or kit   Choose the Processor   Choose the i.MX93 part number product     Choose DDR Under the tool select the tools---->DDR Three sections need to mentioned: Make DDR configure right and make the DDR is enabled already.   Two sections are very important the same as the tool we supply before in the old product: DDR paramaters configuration DDR stress test(Validation)   DDR parameters configuration:   This is the UART Port configure, for the i.MX93 EVK Board default use the UART1 for A55 core debug, if in customer’s design use others port can choose here and also need modify the register settings manually.       Advanced parameters config, it is very important:   General advice The I2C connection between MX and PMIC should be consistent with the development board, using the same pad. If choose different , Need to modify I2C     Validation of DDR configuration In the previous DDR stress test tool, only two functions were provided: DDR calibration and stress test. In the new Config tool, more testing items are provided for customers to debug DDR, totaling four items.   When finished the DDR configuration then go to do the validation.     Test DDR initialization script, Perform basic read and write operations   If pass the test, it will be OK. If failed, we need to fail shooting for it. According to the log output information, check boot mode/UART/USB, etc If the test fails, first check the boot mode configuration and UART/USB interface. The previous DDR stress test tool would output statements such as "Please set in serial download mode" or "Please connect UART port", which are obvious. The current Config tool outputs all log information of the code, with a lot of content and no erroneous conclusions. We need to carefully review the log output to identify where the problem lies. Test on the i.MX93 EVK Board, if the boot mode not right and the USB is not connected, when do the test there will be the ERROR Messages in the logs:   Test on the i.MX93 EVK Board, if not with proper UART port, the ERROR Messages in the logs:   Optimization test This requires detailed ODT, driver strength testing, and scanning of all DQ IO configuration options, Test whether each configuration is passed or failed. Finally, output the mapping between the read/write drive strength and ODT output. For the test result when reading, the impedance of DRAM driven strength and PHY ODT cannot be set too big, (Green - pass, Orange - fail)   When determining the optimal ODT/driver strength value for the customer's board, this mapping diagram can be used as a reference, but it cannot be the sole basis for making this decision. If the customer fully references the NXP development board for design, they can first use the default configuration of the development board for testing. Then fine tune it.     VTSA (Virtual Timing Signal Analysis) Generate write and read data eye diagrams by running a series of write/read operations. (Different from using a high-speed oscilloscope for manual physical TSA (pTSA) measurement). Use the DDR controller itself to test margin by writing margin (Diag Write Margin)/diagnosing read margin (Diag Draw a virtual data eye diagram for each DQ channel during the Read Margin test. This tool differs from the actual eye diagram results and is for reference only.     DDR Stress Test The last step, stress test, customer can choose long time test:     Code generate In the right side we can see the lpddr4_timing.c generate, using for the uboot. For this tool, the code can be automatically generated and automatically generated code when the registers change, and do not need to run the test on the board, this is difference with the old tool.   3 i.MX93 UBOOT and Kernel DDR configuration 3.1 The DDR configuration in the Uboot (1) Copy the generated lpddr4x_timing.c to uboot path: board/freescale/imx93_evk/lpddr4x_timing.c       (2) DDR Size setting uboot-imx/include/configs/imx93_evk.h The default size is 2GB for the i.MX93 EVK board.   For the i.MX93EVK uses 2GB LPDDR4X. If using 1GB/512MB LPDDR4, it is important to note that the size of the DDR is related to the memory map address.   According to the Memory map, starting from 0xC000_0000 is 1GB of DRAM space, and starting from 0xA000_0000 is 512MB of DRAM space.               3.2 The DDR configuration align in the Kernel For the 1GB LDDR4/4X device tree modify For the i.MX93 the NPU is accessed through M-core, so a section of DRAM memory is reserved. Regardless of whether NPU is used or not, ethos must be changed here, otherwise starting the kernel may result in errors. Change the address space to within 1GB and appropriately reduce the memory allocation size. arch/arm64/boot/dts/freescale$ vi imx93-11x11-evk.dts         Summary: Config tool is NXP's new DDR script generation/stress testing/OMUX allocation tool, which is required for i.MX93. Other i MX chips can also use this tool. The Config tool provides more DDR testing projects, including testing ODT/driver capabilities and outputting mapping maps, generating DDR virtual eye diagrams, etc., making it easy to test DDR conditions from multiple perspectives. It is recommended to use the Config tool to debug ODT/driver capabilities and other parameters, which is also applicable to all i MX chip, as a debugging tool for reference. The theoretical parameters of the actual board should refer to the simulation results of the board or the measured results of DDR signals. Any questions contact us freely.  

GUI Guider version: 1.6.x, 1.7.x, 1.8x LVGL version: v8.x.x Host software requirements: Ubuntu 20.04, Ubuntu 22.04 or Debian 12 Hardware requirements: Evaluation Kit for the i.MX 93 Applications Processor. (i.MX 93 Evaluation Kit | NXP Semiconductors) On this guide we will use the IMX-MIPI-HDMI accessory board to connect the iMX93 with a HDMI Monitor. (IMX-MIPI-HDMI Product Information|NXP) This board is usually provided with the iMX8M Mini and the iMX8M Nano.  Steps: 1. Copy your project from the folder GUI-Guider-Projects to your Linux PC.  2. Build an image for iMX93 using The Yocto Project.    a. Based on iMX Yocto Porject Users Guide set directories and download the repo $ mkdir imx-bsp-6.1.1-1.0.0 $ cd imx-bsp-6.1.1-1.0.0 $ repo init -u https://github.com/nxp-imx/imx-manifest -b imx-linux-langdale -m imx-6.1.1-1.0.0.xml $ repo sync Use distro fsl-imx-xwayland and select machine imx93evk and use this commnad with a build folder name: $ MACHINE=imx93evk DISTRO=fsl-imx-xwayland source ./imx-setup-release.sh - b bld-imx93evk b. Use bitbake command to start the build process. Also, add the -c populate_sdk to get the toolchain. $ bitbake imx-image-multimedia -c populate_sdk  c. Install the Yocto toolchain located on <build-folder>/tmp/deploy/sdk/.  $ sudo sh ./fsl-imx-xwayland-glibc-x86_64-imx-image-multimedia-armv8a-imx93evk-toolchain-6.1-langdale.sh d. Install ninja utility on the build host $ sudo apt install ninja-build e. For Ubuntu 20.04 and Ubuntu 22.04, copy the lv_conf.h file from lvgl-simulator to lvgl $ cp lvgl-simulator/lv_conf.h lvgl/ f. Change the interpreter on build.sh from #!/bin/sh to #!/bin/bash. This is an important step! g. Then, enter to linux folder and use the following commands to make build.sh executable $ dos2unix build.sh $ chmod +x build.sh h. Execute the build.sh $ ./build.sh i. Copy the binary to the iMX93 using a USB or SCP.  2. On the target iMX93 follow these steps. a. On Uboot, use fatls interface device:partition fatls mmc 0:1 (Device 0 : Partition 1) With this command, we will be able to list device tree files. => fatls mmc 0:1 b. Select imx93-11x11-evk-rm67199.dtb and use the command editenv fdtfile  => editenv fdtfile Output example edit: imx93-11x11-evk-rm67199.dtb c. In edit command line put the selected device tree .dtb d. Use saveenv command to save environment and continue with the boot process. e. Finally, run the GUI Application $ ./gui_guider&   I hope this article will be helpful. Best regards, Brian.

1. Description: On the i.MX Android camera HAL, It only supports YUYV sensor, regardless of whether the sensor is connected to ISP or ISI. Some users want to customize the sensor format, such as UYVY or raw, they need a guide to do this, this document intends to describe how to implement raw camera sensor on i.MX8MP android, and output raw data. Note: Base on  i.MX 8M plus, Android12_1.0.0.  2. Camera HAL Android's camera hardware abstraction layer (HAL) connects the higher level camera framework APIs in android.hardware.camera2 to your underlying camera driver and hardware. For more detail information, please refer to AOSP document: https://source.android.google.cn/docs/core/camera/camera3_requests_hal?hl=en while on I.MX camera HAL, the camera subsystem can be divided into several parts:   Camera framework:  frameworks\av\camera Camera service:    frameworks\av\services\camera\libcameraservice\ Camera provider: hardware/interfaces/camera/provider/ hardware/google/camera/common/hal/hidl_service/               hidl_service dlopen the camera HAL3. Camera HAL3:   vendor\nxp-opensource\imx\camera\ Camera driver:   vendor/nxp-opensource/kernel_imx/drivers/media/i2c  It's callstack can be list as follow:  There are 2 streams on pipeline, preview stream need 3 buffers and capture stream need 2 buffers: CameraDeviceSessionHwlImpl: ConfigurePipeline, stream 0: id 0, type 0, res 2592x1944, format 0x21, usage 0x3, space 0x8c20000, rot 0, is_phy 0, phy_id 0, size 8388608 CameraDeviceSessionHwlImpl: ConfigurePipeline create capture stream CameraDeviceSessionHwlImpl: ConfigurePipeline, stream 1: id 1, type 0, res 1024x768, format 0x22, usage 0x100, space 0x0, rot 0, is_phy 0, phy_id 0, size 0 CameraDeviceSessionHwlImpl: ConfigurePipeline create preview stream You can use this command to dump the stream input/output: "setprop vendor.rw.camera.test 1" to dump steam 0. "setprop vendor.rw.camera.test 2" to dump steam 1. Before you implement the command, you need to run “su; setenforce 0” to close the SeLinux, the data is dumped as "/data/x-src.data", "/data/x-dst.data", where "x" is the stream id as "0, "1,", "2", ...   Preview Stream Capture Stream ID 1 0 Resolution 1024*768 2592*1944 Format HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED (34) HAL_PIXEL_FORMAT_BLOB (33) Usage 0x900 GRALLOC_USAGE_HW_TEXTURE      (0x100) GRALLOC_USAGE_HW_COMPOSER  (0x800) 0x3 GRALLOC_USAGE_SW_READ_OFTEN Data space 0 HAL_DATASPACE_V0_JFIF  The following usage will be added by framework to distinguish preview and video:GRALLOC_USAGE_HW_VIDEO_ENCODER 3. Raw support  3.1 system modification  The default image for i.MX 8M Plus EVK supports basler + basler and the cameras can work after the image is flashed and boot up, it’s camera with ISP, but we need ISI to process raw. You should refer to Android_User’s_Guide.pdf, you need find the correct version, as Android12_2.0.0 is different with Android12_1.0.0. To make cameras work with Non-default images, execute the following additional commands: Only OV5640 (CSI1) on host： As we use OV2775 which support 1920*1080, unpacked raw12, the json file: 3.2 DTB modification  1. Firstly, change the BoardConfig.mk to generate dtbo-imx8mp-ov2775.img device\nxp\imx8m\evk_8mp\BoardConfig.mk: TARGET_BOARD_DTS_CONFIG += imx8mp-ov2775:imx8mp-evk-ov2775.dtb 2.  Secondly, add imx8mp-evk-ov2775.dts to vendor\nxp-opensource\kernel_imx\arch\arm64\boot\dts\freescale 3. Change imx8mp-evk-ov2775.dts, connect OV2775 to ISI: &isi_0 { status = "okay"; }; &isp_0 { status = "disabled"; }; &dewarp { status = "disabled"; }; 4. Build dtbo image and flash it to board: ./imx-make.sh dtboimage -j4 fastboot flash dtbo dtbo.img  3.3 Sensor driver modification  I use the OV2775 driver from the isp side, be careful that all the function such as g_frame_interval and enum_frame_size should be implemented, or the HAL will get wrong parameters and return error. static struct v4l2_subdev_video_ops ov2775_subdev_video_ops = { .g_frame_interval = ov2775_g_frame_interval, .s_frame_interval = ov2775_s_frame_interval, .s_stream = ov2775_s_stream, }; static const struct v4l2_subdev_pad_ops ov2775_subdev_pad_ops = { .enum_mbus_code = ov2775_enum_mbus_code, .set_fmt = ov2775_set_fmt, .get_fmt = ov2775_get_fmt, .enum_frame_size = ov2775_enum_frame_size, .enum_frame_interval = ov2775_enum_frame_interval, };  3.4 ISI driver modification  We need to add raw format on ISI driver: }, { .name = "RAW12 (SBGGR12)", .fourcc = V4L2_PIX_FMT_SBGGR12, .depth = { 16 }, .color = MXC_ISI_OUT_FMT_RAW12, .memplanes = 1, .colplanes = 1, .mbus_code = MEDIA_BUS_FMT_SBGGR12_1X12, }, { .name = "RAW10 (SGRBG10)", .fourcc = V4L2_PIX_FMT_SGRBG10, .depth = { 16 }, .color = MXC_ISI_OUT_FMT_RAW10, .memplanes = 1, .colplanes = 1, .mbus_code = MEDIA_BUS_FMT_SGRBG10_1X10, } 3.5 Camera HAL modification As there are preview stream and capture stream on the pipeline. GPU does not support raw format, it will print error log when application set raw format:    02-10 18:49:02.162 436 436 E NxpAllocatorHal: convertToMemDescriptor Unsupported fomat PixelFormat::RAW10 02-10 18:49:02.163 2390 2445 E GraphicBufferAllocator: Failed to allocate (1920 x 1080) layerCount 1 format 37 usage 20303: 7 02-10 18:49:02.163 2390 2445 E BufferQueueProducer: [ImageReader-1920x1080f25m2-2390-0](id:95600000002,api:4,p:2148,c:2390) dequeueBuffer: createGraphicBuffer failed 02-10 18:49:02.163 2390 2405 E BufferQueueProducer: [ImageReader-1920x1080f25m2-2390-0](id:95600000002,api:4,p:2148,c:2390) requestBuffer: slot 0 is not owned by the producer (state = FREE) 02-10 18:49:02.163 2148 2423 E Surface : dequeueBuffer: IGraphicBufferProducer::requestBuffer failed: -22 02-10 18:49:02.163 2390 2445 E BufferQueueProducer: [ImageReader-1920x1080f25m2-2390-0](id:95600000002,api:4,p:2148,c:2390) cancelBuffer: slot 0 is not owned by the producer (state = FREE) 02-10 18:49:02.164 2148 2423 E Camera3-OutputStream: getBufferLockedCommon: Stream 1: Can't dequeue next output buffer: Invalid argument (-22)   Modifying the gpu code is not recommended. When preview stream, it's pixel format is fixed to HAL_PIXEL_FORMAT_IMPLEMENTATION_DEFINED, it needs YUYV format, in this patch, we don't convert raw12 to yuyv, just copy the buffer from input to output, so the preview stream is raw12 actually. When capture stream, we use the Blob format, which usually used for JPEG format. when we find the format is Blob pass down by application, camera HAL will copy the buffer from input to output directly. You can check the detail on function ProcessCapturedBuffer(),    4. Application and Tool 4.1 Application  The test application on the attachment “android-Camera2Basic-master_application.7z”, It's basically a common camera application, it set the capture stream format to blob:  Size largest = Collections.max( Arrays.asList(map.getOutputSizes(ImageFormat.JPEG)), new CompareSizesByArea()); mImageReader = ImageReader.newInstance(largest.getWidth(), largest.getHeight(), ImageFormat.JPEG, /*maxImages*/2); 4.2 Tool We use 7yuv tool to check the raw12 format, which is captured by applicable or dump by HAL, you need set the parameter on the right side:   ImageJ tool also can be used to review raw format.

In i.MX51 platfrom the PMIC 13892 also has a internal RTC. We can use this RTC instead of the i.mx51 SRTC. Attached was the implementation of it.

DEVREGS - Is a tool to display and modify a device's registers at runtime. Under Linux, you can access registers, or any area of physical memory through the /dev/mem pseudo-device and the wonders of the mmap system call. To use it, you open the /dev/mem device, mmap the page in which a register is located, then use the pointer returned to read and/or write the data. Boundary Devices, developed a tool known as " devregs  " that allows you to put a little structure around this facility. It allows you to give names to particular physical memory areas and to describe the bits within a register in the text file /etc/devregs.dat. How to read from register : To read one or more registers, use devregs with a single parameter that’s either an address or a register name. Ex : $  devregs 0x73f88000 :0x73f88000    =0x803dffaf If a register address matches a register in /etc/devregs.dat , you’ll see the register name: Ex : $ devregs 0x73f88000 GPIO2_DR:0x73f88000    =0x803dffaf If used with a register name, any bitfields defined will be shown: Ex: devregs UART1_UFCR UART1_UFCR: 0x73fc0090   =0x0801 UART1_UFCR:0x73fc0090    =0x0801       TXTL                      10-15     =0x2       RFDIV                    7 - 9      =0x0       DCEDTE                 6 - 6     = 0x0       RXTL                       0 - 5     = 0x1 How to write to register : Ex : $ devregs GPIO2_GDIR GPIO2_GDIR:0x73f88004    =0x0002c0a4 Ex: $ devregs GPIO2_GDIR 0x2c0a0 GPIO2_GDIR:0x73f88004    =0x0002c0a4 GPIO2_GDIR:0x73f88004 == 0x0002c0a4...0x0002c0a0 Ex: $ devregs GPIO2_GDIR GPIO2_GDIR:0x73f88004    =0x0002c0a0 For more detailed information please go through the following below links : http://boundarydevices.com/i-mx5x-device-register-access/ http://boundarydevices.com/configuring-i-mx6-machines-different-screens-nitrogen6x-sabre-lite/

Configuring RedBoot The configuration is made using a Minicom session that need to be established between host and target through serial port. To have an operational system been executed just on the power on, configure the right for Boot script. The chooses are shown in Boot Script section. To avoid the start of operational system, power on the board and press CTRL-C immediately. Wait until RedBoot> prompt appears. Overview The main command for beginners is fconfig -l that can be abbreviated as fc -l    This command shows the actual configuration of Redboot, like: RedBoot> fc -l Run script at boot: true Boot script: .. load -r -b 0x100000 /tftpboot/zImage .. exec -b 0x100000 -l 0x200000 -c "noinitrd console=ttymxc0,115200 root=/dev/n" Boot script timeout (1000ms resolution): 1 Use BOOTP for network configuration: false Gateway IP address: 10.29.241.254 Local IP address: 10.29.241.6 Local IP address mask: 255.255.254.0 Default server IP address: 10.29.244.99 Board specifics: 0 Console baud rate: 115200 Set eth0 network hardware address [MAC]: false GDB connection port: 9000 Force console for special debug messages: false Network debug at boot time: false RedBoot> Run script at boot: set true for booting with a script or false to always enter on prompt directly Boot script: define what commands to execute as script at the startup Boot script timeout: how many time to wait before execute boot script Use BOOTP for network configuration: set true for getting configuration from BOOTP or false for manually configuring gateway and IP address Gateway IP address: The IP address of the gateway Local IP address: The board IP address Local IP address mask: The board IP mask address Default server IP address: The host IP address when NFS and TFTP server are running Configuring Network Execute the command to configure network parameters: RedBoot> fc This step guarantee the possibilities to load images from some server previously connected and configured. For Use BOOTP for network configuration: answer false. For Gateway IP address: type the gateway IP address of your network; For Local IP address: type an IP address to your board, it needs to be a valid IP in your network; For Local IP address mask: type the IP mask address; For Default server IP address: type the IP of your host server where are running TFTP and NFS. Pay special attencion for Update RedBoot non-volatile configuration - continue (y/n)?. Answer y to have your configuration saved in the flash. To verify if your configuration is working use ping, be patient this command is very slow: RedBoot" ping -h 10.29.244.99 Network PING - from 10.29.241.6 to 10.29.244.99 PING - received 10 of 10 expected Use the "-n" option to change the number of pings and the "-r" option to speed things up, such as: ping -n 3 -h 10.29.244.99 -r 10. The boot script configuration is done in the next section. Boot Script NFS Boot In NFS Boot mode, a kernel image and a root file system image are loaded from a configured server through TFTP and NFS that can be executed doing the development more easy. To configure RedBoot for NFS Boot reset the board and press CTRL-C immediately. In a Minicom session type fc to modify the configuration boot. Enter the script boot below: RedBoot> fc Run script at boot: true Boot script: Enter script, terminate with empty line >> load -r -b 0x100000 /tftpboot/zImage >> exec -b 0x100000 -l 0x200000 -c "noinitrd console=ttymxc0,115200 root=/dev/nfs nfsroot=10.29.244.99:/tftpboot/rootfs init=/linuxrc ip=10.29.241.6:10.29.244.99" >> Boot script timeout (1000ms resolution): 1 Use BOOTP for network configuration: false Gateway IP address: 10.29.241.254 Local IP address: 10.29.241.6 Local IP address mask: 255.255.254.0 Default server IP address: 10.29.244.99 Board specifics: 0 Console baud rate: 115200 Set eth0 network hardware address [MAC]: false GDB connection port: 9000 Force console for special debug messages: false Network debug at boot time: false Update RedBoot non-volatile configuration - continue (y/n)? y ... Read from 0x07ee0000-0x07eff000 at 0x00080000: . ... Erase from 0x00080000-0x000a0000: . ... Program from 0x07ee0000-0x07f00000 at 0x00080000: . RedBoot> The script is composed by two lines. The first line load the kernel image (zImage) by TFTP from /tftpboot, the directory configured in TFTP.\ The second line executes the kernel and mount the root file system using NFS. The path /tftpboot/ltib indicates the path that should be exported in the host machine. (It's the path in the /etc/exports) 10.29.244.99 is the host IP address 10.29.241.6 is the target IP address Flash Boot For flash boot the Boot Script differs a little bit: fis init kernel exec -c "noinitrd console=ttymxc0,115200 root=/dev/mtdblock8 rw rootfstype=jffs2 ip=none" The value for root can be different for each board type.

Environment:   VMware player 15 + ubuntu 18.04 LTS Reference document: i.MX_Yocto_Project_User's_Guide.pdf 1. Software packages for the compilation # sudo apt-get install flex bison gperf build-essential zlib1g-dev # sudo apt-get install lib32ncurses5-dev x11proto-core-dev # sudo apt-get install libx11-dev lib32z1-dev libgl1-mesa-dev # sudo apt-get install tofrodos python-markdown libxml2-utils xsltproc # sudo apt-get install uuid-dev:i386 liblzo2-dev:i386 gcc-multilib g++-multilib # sudo apt-get install subversion openssh-server openssh-client uuid uuid-dev zlib1g-dev # sudo apt-get install liblz-dev lzop liblzo2-2 liblzo2-dev git-core curl # sudo apt-get install python3 python3-pip python3-pexpect python3-git python3-jinja2 pylint3 # sudo apt-get install u-boot-tools mtd-utils android-tools-fsutils # sudo apt-get install openjdk-8-jdk device-tree-compiler aptitude # sudo apt-get install libcurl4-openssl-dev nss-updatedb # sudo apt-get install chrpath texinfo gawk cpio diffstat # sudo apt-get install libncursesw5-dev libssl-dev libegl1-mesa # sudo apt-get install net-tools python libsdl1.2-dev xterm socat # sudo apt-get install icedtea-netx-common icedtea-netx 2. downloading yocto bsp (L5.4.24_2.1.0) # rm -rf ~/bin # mkdir ~/bin # curl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repo # chmod a+x ~/bin/repo # export PATH=~/bin:$PATH   # mkdir imx-yocto-bsp-5.4.24-2.1.0 # cd imx-yocto-bsp-5.4.24-2.1.0 # repo init -u https://source.codeaurora.org/external/imx/imx-manifest -b imx-linux-zeus -m imx-5.4.24-2.1.0.xml # cd .repo/manifests # gedit imx-5.4.24-2.1.0.xml          Modify git to https like below:   <remote fetch="https://git.yoctoproject.org/git" name="yocto"/>   <remote fetch="https://github.com/Freescale" name="community"/>   <remote fetch="https://github.com/openembedded" name="oe"/>   <remote fetch="https://github.com/OSSystems" name="OSSystems"/>   <remote fetch="https://github.com/meta-qt5"  name="QT5"/>   <remote fetch="https://github.com/TimesysGit"  name="Timesys"/>   <remote fetch="https://github.com/meta-rust"  name="rust"/>   <remote fetch="https://git.openembedded.org"  name="python2"/>   <remote fetch="https://source.codeaurora.org/external/imx" name="CAF"/> Save it and exit. # cd ~/ imx-yocto-bsp-5.4.24-2.1.0 # repo sync          Begin to compile i.MX8MQ BSP: # DISTRO=fsl-imx-wayland MACHINE=imx8mqevk source imx-setup-release.sh -b build-wayland          If users want to use chromium, do it like below, otherwise omit the step.        Add CORE_IMAGE_EXTRA_INSTALL += "chromium-ozone-wayland" to local.conf        And use 8 thread to compile BSP # gedit ./conf/local.conf …… BB_NUMBER_THREADS =”4” PARALLEL_MAKE =”-j 4” CORE_IMAGE_EXTRA_INSTALL += "chromium-ozone-wayland" ……          Save it and exit. [comment]          If your ubuntu has 8GB DDR, BB_NUMBER_THREADS can be set to “2”, PARALLEL_MAKE can be set to “-j 2”. # bitbake chromium-ozone-wayland -c fetch # bitbake imx-image-full Use ulimit -n 4096 to solve the issue. Then continue. # bitbake imx-image-full chromium compilation error:          Compile chromium-ozone-wayland separately. # bitbake chromium-ozone-wayland -c cleansstate # bitbake chromium-ozone-wayland -c compile          Use the command to solve the problem. # gedit ../sources/meta-imx/meta-sdk/dynamic-layers/browser-layer/recipes-browser/chromium/chromium-ozone-wayland_%.bbappend DEPENDS += "\         libxkbcommon \         virtual/egl \         wayland \         wayland-native \          mesa         \ "          Add mesa to DEPENDS          Save and exit.          Continue to compile it. # bitbake chromium-ozone-wayland -c compile          done, continue to compile full image   # bitbake imx-image-full Attachment is document in pdf format, which should be clear. NXP TIC team Weidong Sun 08/21/2020

Header 1 Header 2 Video rendering gst-launch videotestsrc ! mfw_v4lsink Audio rendering gst-launch audiotestsrc ! alsasink WAV Audio rendering gst-launch filesrc location=test.wav ! wavparse ! alsasink Video rendering selecting caps gst-launch videotestsrc ! capsfilter name='video/x-raw-yuv,format=(fourcc)I420' ! mfw_v4lsink gst-launch videotestsrc ! 'video/x-raw-yuv,format=(fourcc)I420' ! mfw_v4lsink

The i.MX 6 D/Q/DL/S/SL Linux 3.10.17_1.0.0 GA release is now available on www.freescale.com Files available Name Description L3.10.17_1.0.0_LINUX_DOCS i.MX 6 D/Q/DL/S/SL Linux 3.10.17_1.0.0 GA BSP documentation. y L3.10.17_1.0.0_iMX6QDLS_Bundle i.MX 6 D/Q/DL/S  Linux 3.10.17_1.0.0 GA BSP Binary Demo Files L3.10.17_1.0.0_iMX6SL_Bundle i.MX 6 SL  Linux 3.10.17_1.0.0 GA BSP Binary Demo Files i.MX_6_Vivante_VDK_150_Tools Vivante VTK 1.5 Codec for the i.MX 6 D/Q/DL/S/SL Linux 3.10.17_1.0.0 GA BSP    y L3.10.17_1.0.0_AACP_CODECS AAC Plus Codec for the i.MX 6 D/Q/DL/S/SL Linux 3.10.17_1.0.0 GA BSP y IMX_6_MFG_L3.10.17_1.0.0_TOOL Manufacturing Tool and Documentation for Linux 3.10.17_1.0.0 GA BSP y Target HW boards o   i.MX6DL  SABRE SD board o   i.MX6Q  SABRE SD board o   i.MX6DQ SABRE AI board o   i.MX6DL SABRE AI board o   i.MX6SL EVK board New  Features o   Main BSP New Features on MX6DQ, MX6DL and MX6SL from L3.10.9_1.0.0 GA: SD3.0 reset USB HSIC HWRNG security feature on MX6SL VIIM OTP Fuse in uboot Battery charge LED U-boot USB mass storage support USB Camera on host mode X backend: Adaptive HDMI display support backed by XRandR Main Codec New Features on MX6DQ, MX6DL and MX6SL from L3.10.17_1.0.0 Beta: Bug fix Main Codec New Features on MX6DQ, MX6DL and MX6SL from L3.10.17_1.0.0 Beta: Bug fix Other features not supported found during testing: UART: only support some baud rates like 9600, 115200, can't support high to 4000000 Known issues For known issues and limitations please consult the release notes located in the BSP documentation package.

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 application 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 application 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 application 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.  

 

    Xenomai is real-time framework, which can run seamlessly side-by-side Linux as a co-kernel system, or natively over mainline Linux kernels (with or without PREEMPT-RT patch). The dual kernel nicknamed Cobalt, is a significant rework of the Xenomai 2.x system. Cobalt implements the RTDM specification for interfacing with real-time device drivers. The native linux version, an enhanced implementation of the experimental Xenomai/SOLO work, is called Mercury. In this environment, only a standalone implementation of the RTDM specification in a kernel module is required, for interfacing the RTDM-compliant device drivers with the native kernel. You can get more detailed information from Home · Wiki · xenomai / xenomai · GitLab       I have ported xenomai 3.1 to i.MX Yocto 4.19.35-1.1.0, and currently support ARMv7 and tested on imx6ulevk/imx6ull14x14evk/imx6qpsabresd/imx6dlsabresd/imx6sxsabresdimx6slevk boards. I also did stress test by tool stress-ng on some boards.      You need to git clone https://gitee.com/zxd2021-imx/xenomai-arm.git, and git checkout Linux-4.19.35-1.1.0. (which inlcudes all patches and bb file) and add the following variable in conf/local.conf before build xenomai by command bitake xenomai.  XENOMAI_KERNEL_MODE = "cobalt"  PREFERRED_VERSION_linux-imx = "4.19-${XENOMAI_KERNEL_MODE}" IMAGE_INSTALL_append += " xenomai" DISTRO_FEATURES_remove = "optee" or XENOMAI_KERNEL_MODE = "mercury" PREFERRED_VERSION_linux-imx = "4.19-${XENOMAI_KERNEL_MODE}" IMAGE_INSTALL_append += " xenomai" DISTRO_FEATURES_remove = "optee" If XENOMAI_KERNEL_MODE = "cobalt", you can build dual kernel version. And If XENOMAI_KERNEL_MODE = "mercury", it is single kernel with PREEMPT-RT patch. The following is test result by the command (/usr/xenomai/demo/cyclictest -p 50 -t 5 -m -n -i 1000 😞 //Mecury on 6ULL with stress-ng --cpu 4 --io 2 --vm 1 --vm-bytes 128M --metrics-brief policy: fifo: loadavg: 6.08 2.17 0.81 8/101 534 T: 0 (  530) P:99 I:1000 C:  74474 Min:     23 Act:  235 Avg:   77 Max:    8278 T: 1 (  531) P:99 I:1500 C:  49482 Min:     24 Act:   32 Avg:   56 Max:    8277 T: 2 (  532) P:99 I:2000 C:  36805 Min:     24 Act:   38 Avg:   79 Max:    8170 T: 3 (  533) P:99 I:2500 C:  29333 Min:     25 Act:   41 Avg:   54 Max:    7069 T: 4 (  534) P:99 I:3000 C:  24344 Min:     24 Act:   51 Avg:   60 Max:    7193   //Cobalt on 6ULL with stress-ng --cpu 4 --io 2 --vm 1 --vm-bytes 128M --metrics-brief policy: fifo: loadavg: 7.02 6.50 4.01 8/100 660 T: 0 (  652) P:50 I:1000 C: 560348 Min:      1 Act:   10 Avg:   15 Max:      71 T: 1 (  653) P:50 I:1500 C: 373556 Min:      1 Act:    9 Avg:   17 Max:      78 T: 2 (  654) P:50 I:2000 C: 280157 Min:      2 Act:   14 Avg:   20 Max:      64 T: 3 (  655) P:50 I:2500 C: 224120 Min:      1 Act:   12 Avg:   15 Max:      57 T: 4 (  656) P:50 I:3000 C: 186765 Min:      1 Act:   31 Avg:   19 Max:      53   //Cobalt on 6qp with stress-ng --cpu 4 --io 2 --vm 1 --vm-bytes 512M --metrics-brief policy: fifo: loadavg: 8.11 7.44 4.45 8/156 1057 T: 0 (  917) P:50 I:1000 C: 686106 Min:      0 Act:    3 Avg:    5 Max:      53 T: 1 (  918) P:50 I:1500 C: 457395 Min:      0 Act:    3 Avg:    5 Max:      49 T: 2 (  919) P:50 I:2000 C: 342866 Min:      0 Act:    2 Avg:    4 Max:      43 T: 3 (  920) P:50 I:2500 C: 274425 Min:      0 Act:    3 Avg:    5 Max:      58 T: 4 (  921) P:50 I:3000 C: 228682 Min:      0 Act:    2 Avg:    6 Max:      46   //Cobalt on 6dl with stress-ng --cpu 2 --io 2 --vm 1 --vm-bytes 256M --metrics-brief policy: fifo: loadavg: 3.35 4.15 2.47 1/122 850 T: 0 (  729) P:50 I:1000 C: 608088 Min:      0 Act:    1 Avg:    3 Max:      34 T: 1 (  730) P:50 I:1500 C: 405389 Min:      0 Act:    0 Avg:    4 Max:      38 T: 2 (  731) P:50 I:2000 C: 304039 Min:      0 Act:    1 Avg:    4 Max:      45 T: 3 (  732) P:50 I:2500 C: 243225 Min:      0 Act:    0 Avg:    4 Max:      49 T: 4 (  733) P:50 I:3000 C: 202683 Min:      0 Act:    0 Avg:    5 Max:      38   //Cobalt on 6SX stress-ng --cpu 4 --io 2 --vm 1 --vm-bytes 512M  --metrics-brief policy: fifo: loadavg: 7.51 7.19 6.66 8/123 670 T: 0 (  598) P:50 I:1000 C:2314339 Min:      0 Act:    3 Avg:    8 Max:      60 T: 1 (  599) P:50 I:1500 C:1542873 Min:      0 Act:   15 Avg:    8 Max:      72 T: 2 (  600) P:50 I:2000 C:1157152 Min:      0 Act:    4 Avg:    9 Max:      55 T: 3 (  601) P:50 I:2500 C: 925721 Min:      0 Act:    5 Avg:    9 Max:      57 T: 4 (  602) P:50 I:3000 C: 771434 Min:      0 Act:    6 Avg:    6 Max:      41   //Cobalt on 6Solo lite stress-ng --cpu 4 --io 2 --vm 1 --vm-bytes 512M  --metrics-brief policy: fifo: loadavg: 7.01 7.04 6.93 8/104 598 T: 0 (  571) P:50 I:1000 C:3639967 Min:      0 Act:    9 Avg:    7 Max:      60 T: 1 (  572) P:50 I:1500 C:2426642 Min:      0 Act:    9 Avg:   11 Max:      66 T: 2 (  573) P:50 I:2000 C:1819980 Min:      0 Act:   11 Avg:   10 Max:      57 T: 3 (  574) P:50 I:2500 C:1455983 Min:      0 Act:   12 Avg:   10 Max:      56 T: 4 (  575) P:50 I:3000 C:1213316 Min:      0 Act:    7 Avg:    9 Max:      43   //Cobalt on 7d with stress-ng --cpu 2 --io 2 --vm 1 --vm-bytes 256M --metrics-brief policy: fifo: loadavg: 5.03 5.11 5.15 6/107 683 T: 0 (  626) P:50 I:1000 C:6842938 Min:      0 Act:    1 Avg:    2 Max:      63 T: 1 (  627) P:50 I:1500 C:4561953 Min:      0 Act:    4 Avg:    2 Max:      66 T: 2 (  628) P:50 I:2000 C:3421461 Min:      0 Act:    0 Avg:    2 Max:      69 T: 3 (  629) P:50 I:2500 C:2737166 Min:      0 Act:    3 Avg:    2 Max:      71 T: 4 (  630) P:50 I:3000 C:2280969 Min:      0 Act:    2 Avg:    1 Max:      33   //////////////////////////////////////// Update for Yocto L5.10.52 2.1.0  /////////////////////////////////////////////////////////// New release for Yocto release L5.10.52 2.1.0. You need to git clone https://gitee.com/zxd2021-imx/xenomai-arm and git checkout xenomai-5.10.52-2.1.0. Updating: 1, Upgrade Xenomai to v3.2 2, Enable Dovetail instead of ipipe. Copy xenomai-arm to <Yocto folder>/sources/meta-imx/meta-bsp/recipes-kernel, and add the following variable in conf/local.conf before build Image with xenomai enable by command bitake imx-image-multimedia. XENOMAI_KERNEL_MODE = "cobalt" IMAGE_INSTALL_append += " xenomai" or XENOMAI_KERNEL_MODE = "mercury" IMAGE_INSTALL_append += " xenomai" Notice: If XENOMAI_KERNEL_MODE = "cobalt", you can build dual kernel version. And If XENOMAI_KERNEL_MODE = "mercury", it is single kernel with PREEMPT-RT patch. //////////////////////////////////////// Update for Yocto L5.15.71 2.2.0  /////////////////////////////////////////////////////////// New release for Yocto release L5.15.71 2.2.0. You need to git clone https://gitee.com/zxd2021-imx/xenomai-arm and git checkout xenomai-5.15.71-2.2.0. Updating: 1, Upgrade Xenomai to v3.2.2 Copy xenomai-arm to <Yocto folder>/sources/meta-imx/meta-bsp/recipes-kernel, and add the following variable in conf/local.conf before build Image with xenomai enable by command bitake imx-image-multimedia. XENOMAI_KERNEL_MODE = "cobalt" IMAGE_INSTALL:append += " xenomai" or XENOMAI_KERNEL_MODE = "mercury" IMAGE_INSTALL:append += " xenomai" Notice: If XENOMAI_KERNEL_MODE = "cobalt", you can build dual kernel version. And If XENOMAI_KERNEL_MODE = "mercury", it is single kernel with PREEMPT-RT patch.   ///////// Later update for Later Yocto release, please refer to the following community post //////////// 移植实时Linux方案Xenomai到i.MX ARM64平台 (Enable real-time Linux Xenomai on i.MX ARM64 Platform)   

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

What is HOB? Hob is a graphical user interface for BitBake. Its primary goal is to enable a user to perform common tasks more easily. It basically runs the Bitbake commands on the background while showing a Graphic User Interface. Hob may not work correctly with Daisy metadata as it is getting deprecated in favor of a new web based interface for Yocto under the name Toaster. Here is what you can do with the current version of Hob on the Freescale Community BSP and BSP Release. - Build images - Edit existing image recipes - Create your own image recipes Note: HOB will write the local.conf file and make modifications which may conflict with baking images outside of HOB. In this case you may need to re-run the environment initialization in order to restore the local.conf file. Starting HOB Once the environment has been initialized (using the setup-environment script on the Freescale Community BSP or the fsl-setup-release on the Freescale BSP Release) use the command below. $ hob & The GUI should then appear: You may then select the MACHINE for which you will build and the Layers of your project. HOB  will take and updated the local.conf and bblayers.conf values so the desired BSP layers will already be selected and available MACHINES on these layers will appear on the drop down menu. Once these options are set HOB will parse the recipes and create a dependency tree in order to show available images for that MACHINE. Image File System Types Advance configuration options include image file system types. Please note that HOB does not support the sdcard format so if it is needed it has to be added manually on the local.conf file and then run bitbake outside of HOB. As HOB changed the local.conf file even if the sdcard format was originally available it may be rewrite and no longer available until the following line is added to local.conf. IMAGE_FSTYPES="tar.bz2 ext3 sdcard" Recipes screen On the recipes screen we can see the recipes included on the image and available recipes, then also package groups. Time to bake! After these configurations you may either build the packages using HOB interface or run Bitbake outside of HOB. (In case you wish to have your image on the sdcard format please see the earlier image types clarification) The resulting image will be stored on <BUILD>/tmp/deploy/images/<MACHINE> You may also save your image recipe with the selected customizations.

Check new updated version for with Morty here Step 1 : Get iMX Yocto AVS setup environment Review the steps under Chapter 3 of the i.MX_Yocto_Project_User'sGuide.pdf on the L4.X LINUX_DOCS to prepare your host machine. Including at least the following essential Yocto packages $ sudo apt-get install gawk wget git-core diffstat unzip texinfo \   gcc-multilib build-essential chrpath socat libsdl1.2-dev u-boot-tools Install the i.MX NXP AVS repo Create/Move to a directory where you want to install the AVS yocto build enviroment. Let's call this as <yocto_dir> $ cd <yocto_dir> $ repo init -u https://source.codeaurora.org/external/imxsupport/meta-avs-demos -b master -m imx7d-pico-avs-sdk_4.1.15-1.0.0.xml Download the AVS BSP build environment: $ repo sync Step 2: Setup yocto for Alexa_SDK image with AVS-SETUP-DEMO script: Run the avs-setup-demo script as follows to setup your environment for the imx7d-pico board: $ MACHINE=imx7d-pico DISTRO=fsl-imx-x11 source avs-setup-demo.sh -b <build_sdk> Where <build_sdk> is the name you will give to your build folder. After acepting the EULA the script will prompt if you want to enable: Sound Card selection The following Sound Cards are supported on the build: SGTL (In-board Audio Codec for PicoPi) 2-Mic Conexant The script will prompt if you are going to use the Conexant Card. If not then SGTL will be assumed as your selection Are you going to use Conexant Sound Card [Y/N]? Install Alexa SDK Next option is to select if you want to pre-install the AVS SDK software on the image. Do you want to build/include the AVS_SDK package on this image(Y/N)? If you select YES, then your image will contain the AVS SDK ready to use (after authentication). Note this AVS_SDK will not have WakeWord detection support, but it can be added on runtime. If your selection was NO, then you can always manually fetch and build the AVS_SDK on runtime. All the packages dependencies will be already there, so only fetching the AVS_SDK source code and building it is required. Finish avs-image configuration At the end you will see a text according with the configuration you select for your image build. Next is an example for a Preinstalled AVS_SDK with Conxant Sound Card support and WiFi/BT not enabled. ==========================================================   AVS configuration is now ready at conf/local.conf             - Sound Card = Conexant                                     - AVS_SDK pre-installed                                       You are ready to bitbake your AVS demo image now:               bitbake avs-image                                        ========================================================== Step 3: Build the AVS image Go to your <build_sdk> directory and start the build of the avs-image There are 2 options Regular Build: $ cd <yocto_dir>/<build_sdk> $ bitbake avs-image With QT5 support included: $ cd <yocto_dir>/<build_sdk> $ bitbake avs-image-qt5 The image with QT5 is useful if you want to add some GUI for example to render DisplayCards. Step 4 : Deploying the built images to SD/MMC card to boot on target board. After a build has succesfully completed, the created image resides at <build_sdk>/tmp/deploy/images/imx7d-pico/ In this directory, you will find the imx7d-pico-avs.sdcard image or imx7d-pico-avs-qt5.sdcard, depending on the build you chose on Step3. To Flash the .sdcard image into the eMMC device of your PicoPi board follow the next steps: Download the bootbomb flasher Follow the instruction on Section 4. Board Reflashing of the Quick Start Guide for AVS kit to setup your board on flashing mode. Copy the built SDCARD file $ sudo dd if=imx7d-pico-avs.sdcard of=/dev/sd bs=1M && sync $ sync Properly eject the pico-imx7d board: $ sudo eject /dev/sd NXP Documentation Refer to the Quick Start Quide for AVS SDK to fully setup your PicoPi board with Synaptics 2Mic and PicoPi i.mx7D For a more comprehensive understanding of Yocto, its features and setup; more image build and deployment options and customization, please take a look at the i.MX_Yocto_Project_User's_Guide.pdf document from the Linux documents bundle mentioned at the beginning of this document. For a more detailed description of the Linux BSP, u-boot use and configuration, please take a look at the i.MX_Linux_User's_Guide.pdf document from the Linux documents bundle mentioned at the beginning of this document.

The iMX8QM LVDS has followed work mode, (There are two LVDS modules in IMX8QM): Single mode (LVDS panel connects to one channel) panel 1 and panel 2 can be different panels: Dual channel split mode (The panel needs two LVDS channels, CH0 for 1,3,5,7,... pixels and CH1 for 2,4,6,8,... pixels): Mirror dual mode (The two panels on same LDB PHY should be same panels on pixel clock and resolution, panel 1 and panel 2 are same; panel 3 and panel 4 are same): The reference patch is based on L5.4.3_GA1.0.0 BSP. LVDS single mode and dual channel split mode are supported in default Linux BSP. Patch 0002 can be used to test this dual mode on MEK board, some rework is needed on MEK board:     R194, R195, R208, R209, R213, R214 should be mounted. And the I6263 board can't be connected to LVDS0_CH0 and LVDS0_CH1 at the same time. The I6263 board can't be connected to LVDS1_CH0 and LVDS1_CH1 at the same time too. Note: for iMX8QXP, there is no mirror dual mode support, because its two LVDS ports are from two different LDB modules, there are no CH1 for them: Note: for iMX8QXP dual channel split mode (The pixel order can be switched: LDB1_CH0 for 1,3,5,7,... pixels and LDB2_CH0 for 2,4,6,8,... pixels; or LDB2_CH0 for 1,3,5,7,... pixels and LDB1_CH0 for 2,4,6,8,... pixels), iMX8QM LVDS has no such feature.

The NXP i.MX 8M provides industry leading audio, voice and video processing for applications that scale from consumer home audio to industrial building automation and mobile computers. The i.MX 8M Quad supports multiple audio interfaces as listed below: Besides the general audio input/output function, the audio interfaces will supports following features: - SAI-1 supports up to 16-channels TX (8 lanes) and 16-channels RX (8 lanes) at 384KHz/32-bit. - SAI-5 supports up to 8-channels TX (4 lanes) and 8-channels RX (4 lanes) at 384KHz/32-bit. - SAI-2/3/6 supports up to 2-channels TX (1 lanes) and 2-channels RX (1 lanes) at 384KHz/32-bit. - SAI-2/3/6 support up to 2-channels TX (1 lane) and 2-channels RX (1 lane) at 384KHz/32-bit. - SAI-1 supports glue-less switching between PCM & DSD operation for popular audio DACs - SPDIF-1/2 supports raw capture mode that can save all the incoming bits into audio buffer The SAI-1/2/3/5/6 and SPDIF-1 share GPIO pads on the chip through IOMUX. Common use cases supported by the audio interfaces are listed in the table below (many other configurations are possible). The number is the data lanes supported. For the MCLK pin on each SAI module, it can be configured as either input or output. When configured as output, the SAI_CLK_ROOT from CCM will be routed to the pad output. When configured as input, the external input to the pad will be routed to SAI.MCLK, which can be used as master clock for SAI. Below is the diagram showing the both input/output options, by using SAI1 as the example. Each SAI module supports up to 3 master clock inputs. The TX and RX sub-module inside each SAI can independently select one of the clock inputs as its master clock. This allows TX and RX of one SAI to run from different clock source. The master clock inputs have following options: - SAI.MCLK[1] can be selected from SAI_CLK_ROOT from CCM or SAI.MCLK from IOMUX. This is the most straight-forward clock routing in which SAI only use its own clock source from CCM or IO pad. - SAI.MCLK[2] can be selected from following clock sources:       Any of the SAI_CLK_ROOT from CCM;       Any of the SAI.MCLK from IOMUX;       Other clock sources from SPIDF; - SAI.MCLK[3] has exact same clock source options as SAI.MCLK[2]. This allows both TX and RX can have access to all the options without any dependency between each other. The clock options for master clock on SAI are shown in the diagram blow, by using SAI-1 as an example. The options on MCLK[1] is also available on MCLK[2] and MCLK[3]. The reason to keep this options is to provide the similar SAI clock structure as i.MX6/i.MX7 processors. The configuration of the MUX for master clock are controlled by IOMUXC_GPR registers. They should be configured before SAI clock is enabled to avoid glitches on the clock. Note: Because those MUX on clocks are missed during the design, the actual implementation in the silicon is simplified as shown in the following diagram. All the SAI and SPDIF instances have SDMA support. In order to meet the audio data rate, two SDMA modules are used. Because the SAI-2/3 and SPDIF-1/2 do not require high data throughput, they are assigned to SDMA-1, shared with other peripherals such as UART/SPI. SAI-1/4/5/6 need to support high sample rate & multichannel audio, they are assigned to SDMA-2, which is a dedicated SDMA engine for audio. The SDMA-2 frequency is increased to 500/250 instead of 133/66 to make sure it has enough throughput. In order to allow SW tracking the progress of audio DMA, the TX_SYNC and RX_SYNC of SAI modules are routed to GPT as the external clock input. Since there are totally 6 SAI modules, these signals will be MUXed when connection to GPT. - GPT-4/5/6 external clock input can be selected from the TX_SYNC or RX_SYNC of any 6 SAI modules; - The MUX select is controlled by IOMUXC_GPR register; - The MUX select register for GPT-4/5/6 are fully independent of each other.