Use Raspberry Pi Debug Probe with OpenOCD and i.MX93 FRDM   This document explains the integration process of the Raspberry Pi Debug Probe (Very low cost debugger) with the OpenOCD (On Chip Debugger) tool with the i.MX93 FRDM board.   Also, we will use GDB (GNU DeBugger) to interact with the OpenOCD.   1. Install and Configure OpenOCD   Update and install dependencies sudo apt update sudo apt install build-essential libtool automake pkg-config libusb-1.0-0-dev libhidapi-dev libftdi1-dev libjim-dev jimsh   Clone the OpenOCD repo git clone https://github.com/openocd-org/openocd.git cd openocd   Run ./bootstrap to create the configuration file git submodule update --init --recursive ./bootstrap ./configure --enable-cmsis-dap --enable-hidapi   Make OpenOCD make -j$(nproc) sudo make install   Download the configuration file for i.MX93 You can dowload the  imx93.cfg  in the Table 2. Software requirements on Ubuntu PC of the AN14367 Then, copy the downloaded file to the openocd/tcl/target/ as below: cp ../imx93_new-b42b7c4cac18508442d3df035cec1c6d.cfg tcl/target/imx93.cfg   2. Create UDEV rules   sudo nano /etc/udev/rules.d/99-openocd.rules Add the below in that file: ATTRS{idVendor}=="2e8a", ATTRS{idProduct}=="000c", MODE="660", GROUP="plugdev", TAG+="uaccess"   Reload rules sudo udevadm control --reload-rules && sudo udevadm trigger   3. Connecting the Hardware   To make the DAP works in the i.MX93 FRDM, we must rework the board removing the resistors R3017 and R3018:     Now, we need to connect the Raspberry Pi Debug Probe with the SWD (P14) of our i.MX93 FRDM board:       4. Running the Debug Session   In this moment, with the RP Debug Probe connected, we can Boot the i.MX93 FRDM board and run the below command to start the OpenOCD: $ openocd -s tcl -f interface/cmsis-dap.cfg -c "adapter speed 1000" -f target/imx93.cfg   tic-mpu@tic-mpu:~/Debug_test/openocd$ openocd -s tcl -f interface/cmsis-dap.cfg -c "adapter speed 1000" -f target/imx93.cfg Open On-Chip Debugger 0.12.0+dev-02429-ge4c49d860 (2026-03-21-23:05) Licensed under GNU GPL v2 For bug reports, read http://openocd.org/doc/doxygen/bugs.html adapter speed: 1000 kHz Warn : DEPRECATED: auto-selecting transport "swd". Use 'transport select swd' to suppress this message. Info : Listening on port 6666 for tcl connections Info : Listening on port 4444 for telnet connections Info : Using CMSIS-DAPv2 interface with VID:PID=0x2e8a:0x000c, serial=E6633861A33A1B2C Info : CMSIS-DAP: SWD supported Info : CMSIS-DAP: Atomic commands supported Info : CMSIS-DAP: Test domain timer supported Info : CMSIS-DAP: FW Version = 2.0.0 Info : CMSIS-DAP: Interface Initialised (SWD) Info : SWCLK/TCK = 0 SWDIO/TMS = 0 TDI = 0 TDO = 0 nTRST = 0 nRESET = 0 Info : CMSIS-DAP: Interface ready Info : clock speed 1000 kHz Info : SWD DPIDR 0x5ba02477 Info : imx93.a55.0: hardware has 6 breakpoints, 4 watchpoints Info : [imx93.a55.0] external reset detected Info : [imx93.a55.0] Examination succeed Info : [imx93.m33] Cortex-M33 r1p0 processor detected Info : [imx93.m33] target has 8 breakpoints, 4 watchpoints Info : [imx93.m33] Examination succeed Info : [imx93.ahb] Examination succeed Info : [imx93.a55.0] starting gdb server on 3333 Info : Listening on port 3333 for gdb connections Info : [imx93.m33] starting gdb server on 3334 Info : Listening on port 3334 for gdb connections Info : [imx93.ahb] gdb port disabled   From the Logs, we can see we have two ports: 3333 for Cortex A55 [imx93.a55.0] 3334 for Cortex M33 [imx93.m33]   Install gdb-multiarch   Now, we can install GDB: sudo apt install gdb-multiarch And start a Debug session: $ gdb-multiarch ~/linux-imx/vmlinux   $ gdb-multiarch ~/linux-development/linux-imx/vmlinux GNU gdb (Ubuntu 15.1-1ubuntu1~24.04.1) 15.1 Copyright (C) 2024 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /home/tic-mpu/linux-development/linux-imx/vmlinux... (gdb) target extended-remote localhost:3333 Remote debugging using localhost:3333 0x00000000fff118fc in ?? ()   A simple example of how to read a register with GDB: (gdb) x/xw 0x43810000 0x43810000: 0x02010001     Happy debugging!     Best regards, Salas. 

Attached slides introduce the i.MX95 Power management with following topics: SoC Power Architecture Power Management with BSP Power on/off & Reboot Suspend Implementation Low Power Run

Some customer want to measure DSM power and do some customize in their own board. We supply the the AN13917 to customer already. But some customer also have some questions about it , so here give more details and test for it for customer will more clearly understand and use it. 1 i.MX 93 power mode overview The i.MX 93 supports the following power modes: Run mode: In this mode, the Cortex-A55 CPU is active and running. Some portions can be shut off for power saving. Low-power run mode: This mode is defined as a Low-power run mode with all external power rails on. In this mode, all unnecessary power domains (MIX) can be off. The AONMIX and internal modules, such as OSC24M/PLL, are an exception in this mode. The Cortex CPU in AONMIX handles all the computing and data processing. Cortex-A55 is powered down and DRAM can be in self-refresh/retention mode. Idle mode: This mode is defined as one that a CPU can enter automatically when no threads are engaged, and no high-speed devices are in use. CPU can be put into a power-gated state, but with L3 data retained, DRAM, and bus clocks are reduced. Most of the internal logic is clock-gated; yet is still powered. In this mode, all the external power from PMIC remains the same, and most IPs remain in their state. Therefore, the interrupt response in this mode is quick compared to the Run mode. Suspend mode: This mode is defined as the most power-saving mode since it shuts off all the clocks and all the unnecessary power supplies. In this mode, the Cortex-A55 CPU is fully power gated, all internal digital logic, and the analog circuits that can be powered down are off, and all PHYs are power gated. VDD_SOC(and related digital supply) voltage is reduced to the "Suspend mode" voltage. Compared to Idle, this mode takes a longer time to exit, but it also uses far less energy. BBSM mode: This mode is also called RTC mode. In this mode, to keep RTC and BBSM logic alive, only the power for the BBSM domain remains on. Off mode: In this mode, all power rails are off. 2 Measure the power consumption of the system in the DSM( Deep Sleep Mode) The use case is based on the Suspend mode, which implies the following: CA55 cluster is OFF • MEDIAMIX is OFF • NICMIX is OFF • WAKEUPMIX is OFF • PLL is OFF • 24 M OSC is OFF PMIC is in STBY mode Download the demo images from website: Download the AN13917SW.zip file, upzip it. Copy the uuu and imx93-11x11-evk-dsm.dtb to demo images path. Download the images to board: .\uuu.exe -b emmc_all .\ imx-boot-imx93-11x11-lpddr4x-evk-sd.bin-flash_singleboot  .\imx-image-full-imx93evk.wic To measure the power consumption of the system in the DSM, the steps are as follows: Boot the Linux image with imx93-11x11-evk-DSM.dtb. System boot up with the default dtb, when system boot up change it to the imx93-11x11-evk-DSM.dtb, using the following commends: setenv fdtfile imx93-11x11-evk-dsm.dtb saveenv boot To put the system into the Suspend (Deep sleep) mode, run the following command: echo mem > /sys/power/state Measure the power and record the results. About the BCU Tool: BCU (Board Remote Control Utilities):BCU is a software specially designed to control boards/platforms that support remote control. It provides functions such as on/off key operation, board reset, setting boot mode, controlling GPIO, and power measurement through the debug cable. ------->Remote Control function: $ sudo ./bcu reset sd [-board=xxx] version bcu_1.0.158-0-gdb0a8e5 Auto recognized the board: imx8dxlevk set reset high successfully set onoff high successfully set ft_reset high successfully ENABLE remote control set sd_pwr high successfully set sd_wp high successfully set sd_cd high successfully set boot mode successfully set bootmode_sel low successfully Set ALL sense resistances to smaller ones rebooting... reset successfully done -------->Power measurement function: $ sudo ./bcu monitor -hz=1 [-board=xxx] Here for the power measurement function support the boards have power measurement function. This is the example for the power measurement for the i.MX93 EVK board: 1\Download the BCU tool Releases · nxp-imx/bcu Download the bcu_1.1.100 to Windows 2\Connect the i.MX93 EVK board to Windows PC 3\Open the teminal in the Windows PC C:\Users \Desktop>bcu.exe monitor -board=imx93evk11b1 -hz=1 Use the bcu.exe monitor -board=imx93evk11b1 -hz=1 Make sure the board version is proper, current board is B1 version, so the board name is imx93evk11b1. 4\Run the command in the PC : For others mode test can refer to the BCU.pdf file: https://github.com/nxp-imx/bcu/releases/download/bcu_1.1.100/BCU.pdf Note: To make sure the board version are proper with the related command: bcu.exe monitor -board=imx93evk11b1 -hz=1 For the i.MX93 SOM B2 version Board can use the above command. If the board version is old, such as use the i.MX93 SOM B, here you need to use the command: bcu.exe monitor -board=imx93evk11 If using the bcu.exe monitor -board=imx93evk11b1 the test result are not for this board, here can use the ./bcu eeprom -w -board=imx93evk11 to write the eeprom for the imx93evk11. Using the bcu eeprom -r -board=imx93evk11 see the present status. If we met the problem as bellow we need to check and write to the eeprom again. Measure the power in the DSM mode on the i.MX93 board with SOMB2(board name with the i.mx93evk11b1): old EVK imx93evk11 use a 20m Ohms sensing resistor new EVK imx93evk11b1 use a 5m Ohms sensing resistor For the the i.MX93 board with SOM B Measure the power in the DSM mode on the i.MX93 board with SOMB2 result, use the small and larger range test: Measure the power in the DSM mode on the i.MX93 board with SOMB result: Using the command bcu.exe monitor -board=imx93evk11 -hz=1 3 Questions from customer a.The diff/patch between imx93-11x11-evk.dts and imx93-11x11-evk-dsm.dts If customer use the Linux kernel version: L6.1.55 version BSP, they need to use the imx93-11x11-evk-dsm.dtb we supply. And if using the newer than it and newest BSP in our website, they do not need to change the dtb to the and imx93-11x11-evk-dsm.dtb, just using the imx93-11x11-evk.dts will be OK, as for the Atf  also add the has_wakeup_irq = true;   And in the default imx93-11x11-evk.dts already support the  linux-imx/arch/arm64/boot/dts/freescale/imx93-11x11-evk.dts at lf-6.12.y · nxp-imx/linux-imx · GitHub   So customer and directly use on their products. b. NXP i.MX93 EVK DSM power measurement, the GROUP_SOC_FULL  are some difference from our AN. As different chips may show slight differences in static power consumption(SS TT FF) due to process corner variations.  

  This article shows how to use the i.MX6DL/Q to transcode and stream videos on 1080i/p @ 24fps and 720p @ 30fps. For this test, we used one i.MX6DL as server and an i.MX6DL and i.MX6Q as clients. The video is streamed by the server, playing the sound at the same time, while the clients show the video in the HDMI output, as the image below:     This test depends on some GStreamer plugins. To check that the right GStreamer plugins are installed type the following commands: $ gst-inspect-1.0 | grep h264 To return all the H.264 related plugins, or: $ gst-inspect-1.0 decodebin To check directly the command. To connect more than one board to the minicom, open it with the command: $ sudo minicom –s This way, you open the configuration menu. Enter in the “Serial port setup” option and press “A” to set or change the PORTNUMBER, in “ttyUSB$PORTNUMBER”. To set the HDMI output, run the commands below from the U-Boot prompt: => setenv mmcargs 'setenv bootargs console=ttymxc0,115200 root=/dev/mmcblk2p2 rootwait rw video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24 consoleblank=0' => saveenv Be sure that the IPs are correctly setted: SERVER: => ifconfig eth0 $SERVERIP CLIENTS: => ifconfig eth0 $CLIENTSIP Streaming transcoded video only SERVER: => gst-launch-1.0 filesrc location=/home/root/bbb_720p.mp4 ! decodebin ! queue max-size-buffers=0 ! vpuenc_h264 gop-size=2 bitrate=20000 ! queue max-size-buffers=0 ! rtph264pay config-interval=2 ! queue max-size-buffers=0 ! gdppay ! tcpserversink blocksize=512000 host=$SERVERIP$ port=8554 CLIENTS: => gst-launch-1.0 tcpclientsrc host=$SERVERIP$ port=8554 ! gdpdepay ! queue max-size-buffers=0 ! 'application/x-rtp, media=(string)video, clock10-rate=(int)90000, payload=(int)96' ! queue max-size-buffers=0 ! rtpjitterbuffer latency=100 ! queue max-size-buffers=0 ! rtph264depay ! queue max-size-buffers=0 ! decodebin ! autovideosink sync=false Streaming transcoded video + audio SERVER: => gst-launch-1.0 filesrc location=/home/root/bbb_720p.mp4 ! decodebin name=demux demux. ! queue max-size-buffers=0 ! vpuenc_h264 gop-size=2 bitrate=20000 ! queue max-size-buffers=0 ! rtph264pay config-interval=2 ! queue max-size-buffers=0 ! gdppay ! tcpserversink blocksize=512000 host=$SERVERIP$ port=8554 demux. ! alsasink CLIENTS: => gst-launch-1.0 tcpclientsrc host=$SERVERIP$ port=8554 ! gdpdepay ! queue max-size-buffers=0 ! 'application/x-rtp, media=(string)video, clock10-rate=(int)90000, encoding-name=(string)H264' ! queue max-size-buffers=0 ! rtpjitterbuffer latency=100 ! queue max-size-buffers=0 ! rtph264depay ! queue max-size-buffers=0 ! decodebin ! autovideosink sync=false   You can check the results with the 1080p@24fps.

There are several vulnerabilities been found recently as below: ZIMPERIUM’s report: http://jiveon.jivesoftware.com/mpss/c/7gA/PDcDAA/t.1p4/5z0zjG0pTd2TX1EnZDdFDQ/h3/hAMy2Th8Lsdoz-2BI-2B-2B4FlQpxshE-2Fm9XH3UWXhoYdrt6y4Crt0q1GUsW8pizm7YGWnxGc52SR4U4vCgooHeqoe1S9fu9dc4l1m2ew0Kz-2BSCbA-3D     They are reported as CVE-2015-1538, CVE-2015-1539, CVE-2015-3824, CVE-2015-3826, CVE-2015-3827, CVE-2015-3828 and CVE-2015-3829.   Trendmicro’s  report:http://blog.trendmicro.com/trendlabs-security-intelligence/trend-micro-discovers-vulnerability-that-renders-android-devices-silent/   All above vulnerabilities are related with stagefright’s stackoverflow, which exist all android version since JellyBean 4.2. The stagefright is the default Multimedia framework in Android’s AOSP source code.   To avoid attacking toward stagefright, it is recommended to have patches in this attach, which should be applied to myandroid/frameworks/av.   Reference: https://github.com/WhisperSystems/TextSecure/issues/381   This document was generated from the following discussion: Android vulnerability related with stagefright   Created by Hui Fang

Q: What is quality level of IBIS file? In chapter 8.6 in IMX6DQ6SDLHDG (Rev.0). It says the following about quality assurance. ===== All models (GPIO, DDR, LVDS, MLB) have passed the following checks: • IBISCHK without errors or unexplained warnings • Data for basic simulation checked • Data for timing analysis checked • Data for power analysis checked • Correlated against Spice simulations Validation reports can be provided upon demand. ==== A: In addition, please see http://www.vhdl.org/pub/ibis/quality_wip/checklist/Using_IQ_2.0_checklist.pdf. This document says about quality level. According to these information, the IBIS quality level is IQ4 (IQ3 + data for power  analysis checked) + "Correlated against Spice simulations". This document was generated from the following discussion: IBIS QUALITIY LEVEL

Attached is the Kernel needed to construct the following image: i.MX 6Dual/6Quad Power Consumption Measurement Linux Image

I am designing settop using iMX.6Q sabre solution. What is the android platform key? Why need  the android platform key? Thank in advance

LSIO_GPIO0_IO0x toggling on i.MX8QM Issue customer met: Customer met LSIO_GPIO0_IO0x not toggling on i.MX8QM, they are working through the software on their board, part of that involves getting a few GPIO pins working. They have been using several GPIO pins for a while now, we have some simple toggles and some others where we bit bang i2c, all of those have worked fine. However, They have not been able to get 3 pins to either read or set successfully at all: LSIO_GPIO0_IO00 (SIM0_CLK) LSIO_GPIO0_IO01 (SIM0_RST) LSIO_GPIO0_IO02 (SIM0_IO) 1\ Reproduce on our i.MX8QM EVK board  a. Check the hardware connection Check the LSIO_GPIO0_IO00 (SIM0_CLK), LSIO_GPIO0_IO01 (SIM0_RST) and LSIO_GPIO0_IO02 (SIM0_IO) connection in our i.MX8QM EVK board. In the default design in NXP i.MX8QM EVK board, the pins SIM0_CLK, SIM0_RST and SIM0_IO connect to the SIM CARD on the base board.         b. To make these pins work as GPIO pins In the default pins mux, default pins mux on the SIM0, to make these pins work as GPIO, need to mux them to the GPIO functions. SIM0_CLK (SIM0_CLK)     SIM0_RST (SIM0_RST)   SIM0_IO (SIM0_IO)     c. In the source code change these pins mux to GPIO configuration: Defalt setting for these pins : linux-imx/arch/arm64/boot/dts/freescale/imx8qm-mek.dts at lf-6.12.y · nxp-imx/linux-imx · GitHub   pinctrl_sim0: sim0grp {                              fsl,pins = <                                            IMX8QM_SIM0_CLK_DMA_SIM0_CLK           0xc0000021                                            IMX8QM_SIM0_IO_DMA_SIM0_IO                 0xc2000021                                            IMX8QM_SIM0_PD_DMA_SIM0_PD               0xc0000021                                           IMX8QM_SIM0_POWER_EN_DMA_SIM0_POWER_EN                         0xc0000021                                            IMX8QM_SIM0_RST_DMA_SIM0_RST            0xc0000021                              >;               }; Linux dts should set them to GPIO0 functions:               IMX8QM_SIM0_CLK_LSIO_GPIO0_IO00 0xc0000021               IMX8QM_SIM0_RST_LSIO_GPIO0_IO01 0xc2000021               IMX8QM_SIM0_IO_LSIO_GPIO0_IO02 0xc0000021 Build the source code, download the images to board, test on the SIM pins to see if these pins can work or not. Test on the J45 pins 3,5,6.   Test the SIM_CLK as an example: Test commands in Linux echo 480 > /sys/class/gpio/export echo out > /sys/class/gpio/gpio480/direction #output high echo 1 > /sys/class/gpio/gpio480/value #measure the PINs #output low echo 0 > /sys/class/gpio/gpio480/value #measure the PINs Found these pins can not toggling well. 2\ Go next further test and consideration Foud the SCU_GPIO0_00, SCU_GPIO0_01, SCU_GPIO0_02 are also configurate as GPIO function in the SCFW,  in the default setting for the SC_P_SCU_GPIO0_00is the function GPIO0_00 , and when setting the SIM0_CLK to GPIO0_00 function then the GPIO0_00 can not work normally. So if setting the SIM0_CLK as GPIO0_00 function, then we need to set the SC_P_SCU_GPIO0_00 this PIN to others function, so that no conflict of them. Even no use the pin SC_P_SCU_GPIO0_00 in hardware, we also need to set them to others function to avoid the conflict. SCU_GPIO Pins mux: SCU_GPIO0_00 (SCU_GPIO0_00)   SCU_GPIO0_01 (SCU_GPIO0_01)   SCU_GPIO0_02 (SCU_GPIO0_02)         Tested the PINs "SIM0_CLK, SIM0_IO, SIM0_RST" on iMX8QM MEK with base board. All of them works fine.  The key points are already listed. VDD_SIM0 power should be supplied (It is 3.3V on MEK from PF8100 LDO)   Linux dts should set them to GPIO0 functions:     IMX8QM_SIM0_CLK_LSIO_GPIO0_IO00 0xc0000021     IMX8QM_SIM0_RST_LSIO_GPIO0_IO01 0xc2000021     IMX8QM_SIM0_IO_LSIO_GPIO0_IO02 0xc0000021 The default IOMUX for PINs SC_P_SCU_GPIO0_00, SC_P_SCU_GPIO0_01, SC_P_SCU_GPIO0_02 should be changed from 0 to others.  Test on MEK, we used followed codes in SCFW board_init():     else if (phase == BOOT_PHASE_FINAL_INIT)     {         /* Configure SNVS button for rising edge */         SNVS_ConfigButton(SNVS_DRV_BTN_CONFIG_RISINGEDGE, SC_TRUE);           /* Init PMIC if not already done */         pmic_init();         pad_force_mux(SC_P_SCU_GPIO0_00, 2,             SC_PAD_CONFIG_NORMAL, SC_PAD_ISO_OFF);         pad_force_mux(SC_P_SCU_GPIO0_01, 2,             SC_PAD_CONFIG_NORMAL, SC_PAD_ISO_OFF);         pad_force_mux(SC_P_SCU_GPIO0_02, 2,             SC_PAD_CONFIG_NORMAL, SC_PAD_ISO_OFF);     }  Note: In SCFW, should also set SC_P_SCU_GPIO0_00, SC_P_SCU_GPIO0_01, SC_P_SCU_GPIO0_02 to other functions, because they are set to GPIO0_0x function default, if two PINs set to the same functions, such as SIM0_CLK_DMA pin and SCU_GPIO0_00 pin are set to GPIO0_00 together, the function will not work correctly.   Test commands in LInux: echo 480 > /sys/class/gpio/export echo 481 > /sys/class/gpio/export echo 482 > /sys/class/gpio/export echo out > /sys/class/gpio/gpio480/direction echo out > /sys/class/gpio/gpio481/direction echo out > /sys/class/gpio/gpio482/direction #output high echo 1 > /sys/class/gpio/gpio480/value echo 1 > /sys/class/gpio/gpio481/value echo 1 > /sys/class/gpio/gpio482/value #measure the PINs, they are correct high  ( 3V ) #output low echo 0 > /sys/class/gpio/gpio480/value echo 0 > /sys/class/gpio/gpio481/value echo 0 > /sys/class/gpio/gpio482/value #measure the PINs, they are correct low ( 0V ) The test result is based on real measurement on iMX8QM MEK.    Note: 1\In customer's side If still not work, To confirm the issue, please suggest customer build SCFW with parameter "-m", then use followed commands to dump the IOMUX registers: md 0x41F80000 1 md 0x41F80040 1 md 0x41F80080 1 md 0x41F82140 1 md 0x41F82180 1 md 0x41F83000 1   The "md" command should run from SCFW debug UART, not linux/uboot UART. 2\Make sure the hardware in customer's side VDD_SIM0 power should be supplied .    

Sorry I can't find a place to share this input file. It is to reproduce the VPU JPEG decoder issue I reported in Corrupted MJPG decoding result with FSL 3.10.17 BSP on i.MX6Q VPU​

Hi team, My customer is facing the issue of unexpected behavior of i.MX6Q SSI. The customer uses SSI as slave/Network mode. And they want to transfer 4 time-slot data. As for the register setting, RFEN0, RFEN1 and RDMAE is set to 1. And only first time slot data is transferred. Do you have any ideas about the cause of this? Thanks, Miyamoto This document was generated from the following discussion: 

prebuilt image: image_imx-android-13.4.1_6qsabresd u-boot variables: bootcmd=booti mmc2 bootargs=console=ttymxc0,115200 init=/init androidboot.console=ttymxc0 video=mxcfb0:dev=hdmi,1920x1080M@60,if=RGB24

It is suggested to create a layer when creating or modifying any metadata file (recipe, configuration file or class). The main reason is simple: modularity. Follow these steps 1. To have access to Yocto scripts, setup the enviroment from the BASE folder fsl-community-bsp $ . setup-environment build 2. Move to the place you want to create your layer and choose a name (e.g. `fsl-custom`) sources $ yocto-layer create fsl-custom # Answer the questions. Make sure the priority is set correctly (higher numbers, # higher priorities). Set the priority equal to the lowest already present, except # when you have introduce a new recipe with the same name as other and want to shadow # the original one. 3. Add any metadata content. Suggestion: Version the layer with Git and upload your local git repo to a server 4. Edit and add the layer to the `build/conf/bblayers.conf` file 5. To verify that your layer is *seen* by BitBake, run the following command under the build folder build $ bitbake-layers show-layers This document was generated from the following discussion: i.MX Yocto Proyect: How can I create a new Layer?

Question: The following contradicting information regarding the UART clock tree has been seen in the Rev. 1.0  version of the reference manual: Page 813: PLL3_PFD1 -> divide by 6 -> adjustable post divider -> UART Page 839: PLL3 -> divide by 6 -> UART In the old Rev D I found: Page 803: PLL3 -> divide by 6  ... and something about 80MHz The assumption is that correct path would be: PLL3 -> divide by 6 -> post divider -> UART. Answer: The designer said that UART _CLK_ROOT comes from PLL3 (not PLL3:PFD1) and is divided by 6 to produce 80 MHz. I'm waiting for him to confirm that the divider he mentions is CSCDR1[UART_CLK_PODF].

Assemble wxWidgets version 2.8. TinyX used. Powered by touchscreens 4 "- 8".

ltib 编译的 解码插件包，官网比较难找到的。

If anyone else has been frustrated by the lack of RT1050 support or is new to NXP products, the MCU On Eclipse blog has been a great help.  For example, see the MCUXpresso IDE V10.1.0 with i.MX RT1052 Crossover Processor article for a very clear overview/quickstart on getting the MIMXRT1050-EVK up and running. This document was generated from the following discussion: RT1050 Developer Resource

hi daiane       find the attached log of gstreamer

The documentation is about to present a detailed build steps to implement the verification of the integrity of the rootfs for i.MX8ULP.

Support SSI Master function based on 0001_SSI_ASRC_P2P.patch