i.MX Solutions Knowledge Base

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX Solutions Knowledge Base

Labels

Discussions

Sort by:
Some customer need to run standalone application in i.MX side. This article describe how to run standalone application in uboot and kernel, how to improve application running performance. It takes i.MX8MP as example, which is also suitable for other i.MX platform.
View full article
Issue description: ZQ calibration issue with LPDDR2 memory with two chip selects    Micron has verified it on my customer's board with i.MX6Q. (ECT-SYT-1163 for FIC.pdf) The patch is made based on lp 5.1, see attachment.
View full article
Steps to add support for WPA3 R3 in supplicant and hostapd
View full article
Dynamic voltage and frequency scaling (DVFS) is a power management technique that allows dynamically reducing power consumption of a CPU by dynamically scaling down supply voltage and CPU frequency. Because the internal DCDC of the i.MX RT1170 cannot cover the needed maximum current requirement at the junction temperature of 125 °C, the DVFS technique can be used to reduce current drain for compatibility with the internal DCDC. Lowering the processor frequency dynamically can help reduce the chip input current demand and ensure that the chip can continue to work at the junction temperature of 125 °C. The demo is attached. Only IAR and armgcc versions are enabled. The corresponding Application Note can be downloaded in the below link. https://www.nxp.com/docs/en/application-note/AN13267.pdf
View full article
This post is based on http://boundarydevices.com/using-the-cortex-m4-mcu-on-the-nit6_solox/ The i.MX6 SoloX processor is the first of a kind, coupling a Cortex-A9 with a Cortex-M4 core inside one chip to offer the best of both MPU and MCU worlds. The MCU is perfect for all the real-time tasks whereas the MPU can provide a great UI experience with non real-time OS such as GNU/Linux. This blog post will detail how to build and run source code on the MCU using our Nit6_SoloX. Terminology Before getting any further, here is a list of terms that will be used in this post: MCC: Multi-Core Communication: protocol offered by Freescale for the MCU and MPU to exchange data MCU: Microcontroller Unit such as the ARM Cortex-M series, here referring to the Cortex-M4 MPU: Microprocessor Unit such as the ARM Cortex-A series, here referring to the Cortex-A9 MQX: RTOS provided by Freescale to run their MCUs RTOS: Real-Time Operating System such as MQX or FreeRTOS For the impatient You can download a demo image from here: 20150814-buildroot-nitrogen6x-mcu-demo.img.gz for Nit6_SoloX. As usual, you’ll need to register on our site and agree to the EULA because it contains Freescale content. The image is a 1GB SD card image that can be restored using zcat and dd under Linux. ~$ zcat 20150814-buildroot*.img.gz | sudo dd of=/dev/sdX bs=1M For Windows users, please use Alex Page’s USB Image Tool. This image contains the following components: Linux kernel 3.14.38 from our repo https://github.com/boundarydevices/linux-imx6/tree/boundary-imx_3.14.38_6qp_beta U-Boot v2015.04 from our repo https://github.com/boundarydevices/u-boot-imx6/tree/boundary-imx6sx Development environment setup This section will detail how to set up a Linux machine to be able to build MCU source code. First you need to download the "MQX RTOS for i.MX 6SoloX v4.1.0 releases and patches" file from Freescale website: http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MQX Then you need to untar this archive and apply our patch to add support for the Nit6_SoloX board. ~$ cd && mkdir mqx && cd mqx ~/mqx$ tar xf ~/Downloads/Freescale\ MQX\ RTOS\ 4.1.0\ for\ i.MX\ 6SoloX\ Linux\ Base.tar.gz ~/mqx$ wget http://boundarydevices.com.commondatastorage.googleapis.com/0001-Add-Nit6_SoloX-board-support.patch ~/mqx$ patch -p1 < 0001-Add-Nit6_SoloX-board-support.patch ~/mqx$ find . -name "*.sh" -exec chmod +x {} \; Note that this package comes with a good set of documentation which we invite you to read: doc/Freescale_MQX_RTOS_4.1.0_i.MX_6SoloX_Release_Notes.pdf doc/Getting_Started_with_Freescale_MQX_RTOS_on_i.MX_6SoloX.pdf As specified in the documentation, you need to install a specific toolchain (CodeSourcery v2014q1) in order to build the BSP. ~$ cd && mkdir toolchains && cd toolchains ~/toolchains$ wget https://launchpad.net/gcc-arm-embedded/4.8/4.8-2014-q1-update/+download/gcc-arm-none-eabi-4_8-2014q1-20140314-linux.tar.bz2 ~/toolchains$ tar xjf gcc-arm-none-eabi-4_8-2014q1-20140314-linux.tar.bz2 ~/toolchains$ rm gcc-arm-none-eabi-4_8-2014q1-20140314-linux.tar.bz2 Your machine is now ready to build applications for the MCU! Build instructions This section explains how to build the BSP as well as the applications for the MCU only. In order to build the BSP for the MPU, please refer to other blog posts on either Yocto or Buildroot. ~$ cd ~/mqx/ ~/mqx$ export TOP=$PWD ~/mqx$ export TOOLCHAIN_ROOTDIR=$HOME/toolchains/gcc-arm-none-eabi-4_8-2014q1/ ~/mqx$ cd $TOP/build/imx6sx_nit6sx_m4/make ~/mqx$ ./build_gcc_arm.sh As the BSP for our board is now built, we can build any example application provided in the MQX package. In order to have an interaction between the MPU and the MCU, you need to build a MCC application. Below are the instructions to build the pingpong application which sends data back and forth between the cores. ~/mqx$ cd $TOP/mcc/examples/pingpong/build/make/pingpong_example_imx6sx_nit6sx_m4/ ~/mqx$ ./build_gcc_arm.sh ~/mqx$ $TOOLCHAIN_ROOTDIR/bin/arm-none-eabi-objcopy \        ./gcc_arm/ram_release/pingpong_example_imx6sx_nit6sx_m4.elf \        -O binary m4_fw.bin That's it, the binary is ready to be used! Some might be interested in using an IDE to browse/modify/build the source code, note that Freescale provides instructions to use IAR Workbench (Windows only). It seems that there isn't any plan to support the SoloX MQX release inside the KSDK (Kinetis SDK) as explained in a community forum post. Run the demo First you need to copy the image (20150814-buildroot-nitrogen6x-mcu-demo.img.gz) provided at the beginning of this post to an SD Card. Then copy the m4_fw.bin binary to the root directory of the SD Card. The SD Card contains the U-Boot version that enables the use of the Cortex-M4, the bootloader inside your NOR must therefore be upgraded. U-Boot > setenv bootfile u-boot.imx U-Boot > run upgradeu Once the upgrade is complete and the board restarted, make sure to have a clean environment: U-Boot > env default -a ## Resetting to default environment U-Boot > saveenv By default, the M4 must be flashed in NOR memory, a U-Boot command has been added to look for the m4_fw.bin as the root of any external storage (SD, USB, SATA): U-Boot > run m4update This command will download the firmware from external storage to RAM and flash it at the offset 0x1E0000 of the NOR. While debugging on the MCU, you might wish not to write every firmware into NOR so we've added a command that loads the M4 firmware directly from external storage. U-Boot > setenv m4boot 'run m4boot_ext' Before going any further, make sure to hook up the second serial port to your machine as the one marked as "console" will be used for U-Boot and the other one will display data coming from the MCU. In order to start the MCU at boot up, we need to set a variable that will tell the 6x_bootscript to load the firmware into OCRAM. If you wish to start the MCU at every boot, make sure to save this variable. U-Boot > setenv m4enabled 1 U-Boot > boot While the kernel is booting, you should see the following prompt on the MCU serial output: ***** MCC PINGPONG EXAMPLE ***** Please wait :   1) A9 peer is ready   Then press "S" to start the demo ******************************** Press "S" to start the demo : Press the S key as requested above on the MCU serial console and then log into Buildroot on the MPU serial output (login is root, no password). You now need to enable the MPU side of the communication before starting the demo: # echo 1 > /sys/bus/platform/drivers/imx6sx-mcc-test/mcctest.15/pingpong_en & A9 mcc prepares run, MCC version is 002.000 test/mcctest.15/pingpong_en & # Main task received a msg from [1, 0, 2] endpoint Message: Size=0x00000004, data = 0x00000002 Main task received a msg from [1, 0, 2] endpoint Message: Size=0x00000004, data = 0x00000004 ... That's it, you've built a MCU application from scratch and can now start exploring all the examples provided inside the MQX SoloX release.
View full article
This blog post will present the architecture of the i.MX6SoloX and i.MX7D processors and explain how to build and run the FreeRTOS BSP v1.0.1 on the MCU. Both processors are coupling a Cortex-A with a Cortex-M4 core inside one chip to offer the best of MPU and MCU worlds (see i.MX7D diagram). Content below will apply for our Nit6_SoloX and Nitrogen7 platforms. For the impatient You can download a demo image from here: 20160804-buildroot-nitrogen6sx-freertos-demo.img.gz for Nit6_SoloX 20160804-buildroot-nitrogen7-freertos-demo.img.gz for Nitrogen7 As usual, you’ll need to register on our site and agree to the EULA because it contains NXP content. The image is a 1GB SD card image that can be restored using zcat and dd under Linux. ~$ zcat 20160804-buildroot*.img.gz | sudo dd of=/dev/sdX bs=1M For Windows users, please use Alex Page’s USB Image Tool. This image contains the following components: Linux kernel 4.1.15 U-Boot v2016.03 FreeRTOS 1.0.1 demo apps Please make sure to update U-Boot from its prompt before getting started: => run clearenv => run upgradeu After the upgrade, the board should reset, you can start your first Hello World application on the Cortex-M4: => run m4update => run m4boot Architecture As an introduction, here is the definition of terms that will be used throughout the post: MCU: Microcontroller Unit such as the ARM Cortex-M series, here referring to the Cortex-M4 MPU: Microprocessor Unit such as the ARM Cortex-A series, here referring to the Cortex-A9/A7 RTOS: Real-Time Operating System such as FreeRTOS or MQX The i.MX6SX and i.MX7 processors offer an MCU and a MPU in the same chip, this is called a Heterogeneous Multicore Processing Architecture. How does it work? The first thing to know is that one of the cores is the "master", meaning that it is in charge to boot the other core which otherwise will stay in reset. The BootROM will always boot the Cortex-A core first. In this article, it is assumed that U-Boot is the bootloader used by your system. The reason is that U-Boot provides a bootaux command which allows to start the Cortex-M4. Once started, both CPU are on their own, executing different instructions at different speeds. Where is the code running from? It actually depends on the application linker script used. When GCC is linking your application into an ELF executable file, it needs to know the code location in memory. There are several options in both processors, code can be located in one of the following: TCM (Tightly Coupled Memory): 32kB available OCRAM: 32kB available If not using the EPDC, 128kB can be used but requires to modify the ocram linker script DDR: up to 1MB available QSPI flash (not available for ou Nit6_SoloX): 128kB allocated on Nitrogen7 Note that the TCM is the preferred option when possible since it offers the best performances since it is an internal memory dedicated to the Cortex-M4. External memories, such as the DDR or QSPI, offer more space but are also much slower to access. In this article, it is assumed that every application runs from the TCM. When is the MCU useful? The MCU is perfect for all the real-time tasks whereas the MPU can provide a great UI experience with non real-time OS such as GNU/Linux. We insist here on the fact that the Linux kernel is not real-time, not deterministic whereas FreeRTOS on Cortex-M4 is. Also, since its firmware is pretty small and fast to load, the MCU can be fully operating within a few hundred milliseconds whereas it usually takes Linux OS much longer to be operational. Examples of applications where the MCU has proven to be useful: Motor control: DC motors only perform well in a real-time environment since feedback response time is crucial Automotive: CAN messages can be handled by the MCU and operational at a very early stage Resource Domain Controller (RDC) Since both cores can access the same peripherals, a mechanism has been created to avoid concurrent access, allowing to ensure a program's behavior on one core does not depend on what is executed/accessed on the other core. This mechanism is the RDC, it can be used to grant peripheral and memory access permissions to each core. The examples and demo applications in the FreeRTOS BSP use RDC to allocate peripheral access permission. When running the ARM Cortex-A application with the FreeRTOS BSP example/demo, it is important to respect the reserved peripheral. The FreeRTOS BSP application has reserved peripherals that are used only by ARM Cortex-M4, and any access from ARM Cortex-A core on those peripherals may cause the program to hang. The default RDC settings are: The ARM Cortex-M4 core is assigned to RDC domain 1, and ARM Cortex-A core and other bus masters use the default assignment (RDC domain 0). Every example/demo has its specific RDC setting in its hardware_init.c. Most of them are set to exclusive access. The user of this package can remove or change the RDC settings in the example/demo or in his application. It is recommended to limit the access of a peripheral to the only core using it when possible. Also, in order for a peripheral not to show up as available in Linux, it is mandatory to disable it in the device, which is why a specific device tree is used when using the MCU: imx7d-nitrogen7-m4.dts The memory declaration is also modified in the device tree above in order to reserve some areas for FreeRTOS and/or shared memory. Remote Processor Messaging (RPMsg) The Remote Processor Messaging (RPMsg) is a virtio-based messaging bus that allows Inter Processor Communications (IPC) between independent software contexts running on homogeneous or heterogeneous cores present in an Asymmetric Multi Processing (AMP) system. The RPMsg API is compliant with the RPMsg bus infrastructure present in upstream Linux 3.4.x kernel onward. This API offers the following advantages: No data processing in the interrupt context Blocking receive API Zero-copy send and receive API Receive with timeout provided by RTOS Note that the DDR is used by default in RPMsg to exchange messages between cores. Here are some links with more details on the implementation: RPMsg_RTOS_Layer_User's_Guide.pdf https://www.kernel.org/doc/Documentation/rpmsg.txt Where can I find more documentation? The BSP actually comes with some documentation which we recommend reading in order to know more on the subject: FreeRTOS_BSP_1.0.1_i.MX_7Dual_Release_Notes.pdf FreeRTOS_BSP_for_i.MX_7Dual_Demo_User's_Guide.pdf FreeRTOS_BSP_i.MX_7Dual_API_Reference_Manual.pdf Getting_Started_with_FreeRTOS_BSP_for_i.MX_7Dual.pdf Build instructions Development environment setup In order to build the FreeRTOS BSP, you first need to download and install a toolchain for ARM Cortex-M processors. ~$ cd && mkdir toolchains && cd toolchains ~/toolchains$ wget https://launchpad.net/gcc-arm-embedded/4.9/4.9-2015-q3-update/+download/gcc-arm-none-eabi-4_9-2015q3-20150921-linux.tar.bz2 ~/toolchains$ tar xjf gcc-arm-none-eabi-4_9-2015q3-20150921-linux.tar.bz2 ~/toolchains$ rm gcc-arm-none-eabi-4_9-2015q3-20150921-linux.tar.bz2 FreeRTOS relies on cmake to build, so you also need to make sure the following packages are installed on your machine: ~$ sudo apt-get install make cmake Download the BSP The FreeRTOS BSP v1.0.1 is available from our GitHub freertos-boundary repository. ~$ git clone https://github.com/boundarydevices/freertos-boundary.git freertos ~$ cd freertos Depending on the processor/board you plan on using, the branch is different. For Nit6_SoloX (i.MX6SX), use the imx6sx_1.0.1 branch. ~/freertos$ git checkout origin/imx6sx_1.0.1 -b imx6sx_1.0.1 For Nitrogen7 (i.MX7D), use the imx7d_1.0.1 branch. ~/freertos$ git checkout origin/imx7d_1.0.1 -b imx7d_1.0.1 Finally, you need to export the ARMGCC_DIR variable so FreeRTOS knows your toolchain location. ~/freertos$ export ARMGCC_DIR=$HOME/toolchains/gcc-arm-none-eabi-4_9-2015q3/ Build the FreeRTOS apps First, here is a quick overview of what the FreeRTOS BSP looks like: All the applications are located under the examples folder: examples/imx6sx_nit6sx_m4/ for Nit6_SoloX examples/imx7d_nitrogen7_m4/ for Nitrogen7 As an example, we will build the helloworld application for Nitrogen7: ~/freertos$ cd examples/imx7d_nitrogen7_m4/demo_apps/hello_world/armgcc/ ~/freertos/examples/imx7d_nitrogen7_m4/demo_apps/hello_world/armgcc$ ./build_all.sh ~/freertos/examples/imx7d_nitrogen7_m4/demo_apps/hello_world/armgcc$ ls release/ hello_world.bin hello_world.elf hello_world.hex hello_world.map The build_all.sh script builds both debug and release binaries. If you don't have a JTAG to debug with, the debug target can be discarded. You can then copy that hello_world.bin firmware to the root of an SD card to flash it. Run the demo apps Basic setup First you need to flash the image provided at the beginning of this post to an SD Card. The SD Card contains the U-Boot version that enables the use of the Cortex-M4 make sure to update it as explained in the impatient section. By default, the firmware is loaded from NOR to TCM. You can execute m4update to upgrade the firmware in NOR. It will look for file named m4_fw.bin as the root of any external storage (SD, USB, SATA) and flash it at the offset 0x1E0000 of the NOR: => run m4update If you wish to flash a file named differently, you can modify the m4image variable as follows: => setenv m4image While debugging on the MCU, you might wish not to write every firmware into NOR so we've added a command that loads the M4 firmware directly from external storage. => setenv m4boot 'run m4boot_ext' Before going any further, make sure to hook up the second serial port to your machine as the one marked as "console" will be used for U-Boot and the other one will display data coming from the MCU. In order to start the MCU automatically at boot up, we need to set a variable that will tell the 6x_bootscript to load the firmware. To do so, make sure to save this variable. => setenv m4enabled 1 => saveenv This blog post only considers the TCM as the firmware location for execution. If you wish to use another memory, such as the OCRAM or QSPI or DDR, you can specify it with U-Boot variables. => setenv m4loadaddr => setenv m4size Note that the linker script must be different for a program to be executed from another location. Also, the size reserved in NOR right now is 128kB. Hello World app The Hello World project is a simple demonstration program that uses the BSP software. It prints the "Hello World" message to the ARM Cortex-M4 terminal using the BSP UART drivers. The purpose of this demo is to show how to use the UART and to provide a simple project for debugging and further development. In U-Boot, type the following: => setenv m4image hello_world.bin => run m4update => run m4boot On the second serial port, you should see the following output: Hello World! You can then type anything in that terminal, it will be echoed back to the serial port as you can see in the source code. RPMsg TTY demo This demo application demonstrates the RPMsg remote peer stack. It works with Linux RPMsg master peer to transfer string content back and forth. The Linux driver creates a tty node to which you can write to. The MCU displays what is received, and echoes back the same message as an acknowledgement. The tty reader on ARM Cortex-A core can get the message, and start another transaction. The demo demonstrates RPMsg’s ability to send arbitrary content back and forth. In U-Boot, type the following: => setenv m4image rpmsg_str_echo_freertos_example.bin => run m4update => boot On the second serial port, you should see the following output: RPMSG String Echo FreeRTOS RTOS API Demo... RPMSG Init as Remote Once Linux has booted up, you need to load the RPMsg module so the communication between the two cores can start. # modprobe imx_rpmsg_tty imx_rpmsg_tty rpmsg0: new channel: 0x400 -> 0x0! Install rpmsg tty driver! # echo test > /dev/ttyRPMSG The last command above writes into the tty node, which means that the Cortex-M4 should have received data as it can be seen on the second serial port. Name service handshake is done, M4 has setup a rpmsg channel [0 ---> 1024] Get Message From Master Side : "test" [len : 4] Get New Line From Master Side RPMsg Ping Pong demo Same as previous demo, this one demonstrates the RPMsg communication. After the communication channels are created, Linux OS transfers the first integer to FreeRTOS OS. The receiving peer adds 1 to the integer and transfers it back. The loop continues infinitely. In U-Boot, type the following: => setenv m4image rpmsg_pingpong_freertos_example.bin => run m4update => boot On the second serial port, you should see the following output: RPMSG PingPong FreeRTOS RTOS API Demo... RPMSG Init as Remote Once Linux has booted up, you need to load the RPMsg module so the communication between the two cores can start. # modprobe imx_rpmsg_pingpong imx_rpmsg_pingpong rpmsg0: new channel: 0x400 -> 0x0! # get 1 (src: 0x0) get 3 (src: 0x0) get 5 (src: 0x0) ... While you can send the received data from the MCU on the main serial port, you can also see the data received from the MPU on the secondary serial port. Name service handshake is done, M4 has setup a rpmsg channel [0 ---> 1024] Get Data From Master Side : 0 Get Data From Master Side : 2 Get Data From Master Side : 4 ... That's it, you should now be able to build, modify, run and debug
View full article
Hi, RAW is still often used in automotive applications. If you are doing bare metal code and if you use OS (QNX, GreenHills integrity), it is often a pain to boot from NAND. On SABRE AI, you have a NAND socket, this document will present you the basics command to reverse engineer the NAND boot setup of a SABRE AI. KOBS-NG What you can do first is understand kobs-ng application, and try to understand it...sources are available on freescale's GIT: http://sw-git.freescale.net/cgi-bin/gitweb.cgi?p=linux-kobs.git;a=summary Anyway, the sequencing is not obvious... Modified MFGtool (see enclosed archive) What you can do also it to program a NAND flash on a SABRE board for instance and read back the NAND flash. First configure your SABRE AI board: S2: 0001 S1: 0001100000  (I use 8 BBT and FCB to be more secure) BOOT_MODE: 0010 (if your NAND flash is not already programmed, otherwise 0100) Copy my mfgtool (Works only with i.MX6 Solo part), and unzip it. Plug  a micro USB cable and a RS232 cable, configure your hyperterminal as usual. Launch mfgtool and press start: Wait the end of programmation: Note: I did modify ucl2.xml file to have 8 BBT and FCB (see S1 configuration above, and "--search_exponent=3" --> 2^3=8 instead of default 2^2=4 ) and I did add the "-v" option in ucl2.xml file to have the verbose mode (thus memory addresses of FCB, BBT and more are displayed) ---> you have to go on the extreme right of the lines below... depending of the witdth of your screen): <!--burn the uboot to NAND: -->    <CMD   state = "Updater"   type = "push"   body = "send"   file = "files/u-boot-mx6solo-sabreauto-nand.bin" > Sending U-Boot </CMD>   <CMD   state = "Updater"   type = "push"   body = "$ kobs-ng init -v --search_exponent=3 --chip_0_device_path=/dev/mtd0 $FILE" > Flashing Bootloader </CMD> ‍‍‍‍‍‍‍‍‍‍‍ Set BOOT_MODE switches: 0010 and press reset. After u-boot startup press a key in the terminal to stop execution. Now you can explore your NAND! have a look in the enclosed "mx6Solo_RAW_NAND_SABRE_AI_programming_verbose.txt" file, you have all the adressses of BBT, FCB, etc...: Firmware: image #0 @ 0x400000 size 0x2a000 - available 0x600000 Firmware: image #1 @ 0xa00000 size 0x2a000 - available 0x600000 -------------- Start to write the [ FCB ] ----- mtd: erasing @0:0x0-0x80000 mtd: Writing FCB0 [ @0:0x0 ] (10e0) * mtd: Writing FCB1 [ @0:0x40000 ] (10e0) * mtd: erasing @0:0x80000-0x100000 mtd: Writing FCB2 [ @0:0x80000 ] (10e0) * mtd: Writing FCB3 [ @0:0xc0000 ] (10e0) * mtd: erasing @0:0x100000-0x180000 mtd: Writing FCB4 [ @0:0x100000 ] (10e0) * mtd: Writing FCB5 [ @0:0x140000 ] (10e0) * mtd: erasing @0:0x180000-0x200000 mtd: Writing FCB6 [ @0:0x180000 ] (10e0) * mtd: Writing FCB7 [ @0:0x1c0000 ] (10e0) * mtd_commit_bcb(FCB): status 0   -------------- Start to write the [ DBBT ] ----- mtd: erasing @0:0x200000-0x280000 mtd: Writing DBBT0 [ @0:0x200000 ] (1000) * mtd: Writing DBBT1 [ @0:0x240000 ] (1000) * mtd: erasing @0:0x280000-0x300000 mtd: Writing DBBT2 [ @0:0x280000 ] (1000) * mtd: Writing DBBT3 [ @0:0x2c0000 ] (1000) * mtd: erasing @0:0x300000-0x380000 mtd: Writing DBBT4 [ @0:0x300000 ] (1000) * mtd: Writing DBBT5 [ @0:0x340000 ] (1000) * mtd: erasing @0:0x380000-0x400000 mtd: Writing DBBT6 [ @0:0x380000 ] (1000) * mtd: Writing DBBT7 [ @0:0x3c0000 ] (1000) * mtd_commit_bcb(DBBT): status 0‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ to read the NAND, I read it in internal OCRAM ( address is 0x918000 for i.MX6DL and Solo) and then I display it): You can read the DCD of one of the boot image (first one is at address 0x400000 as you can see in the enclosed text file): Firmware: image #0 @ 0x400000 size 0x2a000 - available 0x600000 Firmware: image #1 @ 0xa00000 size 0x2a000 - available 0x600000‍‍‍‍‍‍ So, let's read the begenning of the image... at offset 0x400, you'll see the barker code of the DCD: 0x402000D1: MX6SOLO SABREAUTO U-Boot > nand read 0x918000 0x400000 0x800 NAND read: device 0 offset 0x400000, size 0x800 2048 bytes read: OK MX6SOLO SABREAUTO U-Boot > md 0x918000 0x500 00918000: ea000186 00000000 00000000 00000000 ................ 00918010: 00000000 00000000 00000000 00000000 ................ 00918020: 00000000 00000000 00000000 00000000 ................ 00918030: 00000000 00000000 00000000 00000000 ................ 00918040: 00000000 00000000 00000000 00000000 ................ 00918050: 00000000 00000000 00000000 00000000 ................ 00918060: 00000000 00000000 00000000 00000000 ................ 00918070: 00000000 00000000 00000000 00000000 ................ 00918080: 00000000 00000000 00000000 00000000 ................ 00918090: 00000000 00000000 00000000 00000000 ................ 009180a0: 00000000 00000000 00000000 00000000 ................ 009180b0: 00000000 00000000 00000000 00000000 ................ 009180c0: 00000000 00000000 00000000 00000000 ................ 009180d0: 00000000 00000000 00000000 00000000 ................ 009180e0: 00000000 00000000 00000000 00000000 ................ 009180f0: 00000000 00000000 00000000 00000000 ................ 00918100: 00000000 00000000 00000000 00000000 ................ 00918110: 00000000 00000000 00000000 00000000 ................ 00918120: 00000000 00000000 00000000 00000000 ................ 00918130: 00000000 00000000 00000000 00000000 ................ 00918140: 00000000 00000000 00000000 00000000 ................ 00918150: 00000000 00000000 00000000 00000000 ................ 00918160: 00000000 00000000 00000000 00000000 ................ 00918170: 00000000 00000000 00000000 00000000 ................ 00918180: 00000000 00000000 00000000 00000000 ................ 00918190: 00000000 00000000 00000000 00000000 ................ 009181a0: 00000000 00000000 00000000 00000000 ................ 009181b0: 00000000 00000000 00000000 00000000 ................ 009181c0: 00000000 00000000 00000000 00000000 ................ 009181d0: 00000000 00000000 00000000 00000000 ................ 009181e0: 00000000 00000000 00000000 00000000 ................ 009181f0: 00000000 00000000 00000000 00000000 ................ 00918200: 00000000 00000000 00000000 00000000 ................ 00918210: 00000000 00000000 00000000 00000000 ................ 00918220: 00000000 00000000 00000000 00000000 ................ 00918230: 00000000 00000000 00000000 00000000 ................ 00918240: 00000000 00000000 00000000 00000000 ................ 00918250: 00000000 00000000 00000000 00000000 ................ 00918260: 00000000 00000000 00000000 00000000 ................ 00918270: 00000000 00000000 00000000 00000000 ................ 00918280: 00000000 00000000 00000000 00000000 ................ 00918290: 00000000 00000000 00000000 00000000 ................ 009182a0: 00000000 00000000 00000000 00000000 ................ 009182b0: 00000000 00000000 00000000 00000000 ................ 009182c0: 00000000 00000000 00000000 00000000 ................ 009182d0: 00000000 00000000 00000000 00000000 ................ 009182e0: 00000000 00000000 00000000 00000000 ................ 009182f0: 00000000 00000000 00000000 00000000 ................ 00918300: 00000000 00000000 00000000 00000000 ................ 00918310: 00000000 00000000 00000000 00000000 ................ 00918320: 00000000 00000000 00000000 00000000 ................ 00918330: 00000000 00000000 00000000 00000000 ................ 00918340: 00000000 00000000 00000000 00000000 ................ 00918350: 00000000 00000000 00000000 00000000 ................ 00918360: 00000000 00000000 00000000 00000000 ................ 00918370: 00000000 00000000 00000000 00000000 ................ 00918380: 00000000 00000000 00000000 00000000 ................ 00918390: 00000000 00000000 00000000 00000000 ................ 009183a0: 00000000 00000000 00000000 00000000 ................ 009183b0: 00000000 00000000 00000000 00000000 ................ 009183c0: 00000000 00000000 00000000 00000000 ................ 009183d0: 00000000 00000000 00000000 00000000 ................ 009183e0: 00000000 00000000 00000000 00000000 ................ 009183f0: 00000000 00000000 00000000 00000000 ................ 00918400: 402000d1 27800620 00000000 2780042c .. @ ..'....,..' 00918410: 27800420 27800400 00000000 00000000 ..'...'........ 00918420: 27800000 0002a0a4 00000000 40e001d2 ...'...........@ 00918430: 04dc01cc 74070e02 00000c00 54070e02 .......t.......T 00918440: 00000000 ac040e02 30000000 b0040e02 ...........0.... 00918450: 30000000 64040e02 30000000 90040e02 ...0...d...0.... 00918460: 30000000 4c070e02 30000000 94040e02 ...0...L...0.... 00918470: 30000000 a0040e02 00000000 b4040e02 ...0............ 00918480: 30000000 b8040e02 30000000 6c070e02 ...0.......0...l 00918490: 30000000 50070e02 00000200 bc040e02 ...0...P........ 009184a0: 28000000 c0040e02 28000000 c4040e02 ...(.......(.... 009184b0: 28000000 c8040e02 28000000 60070e02 ...(.......(...` 009184c0: 00000200 64070e02 28000000 70070e02 .......d...(...p 009184d0: 28000000 78070e02 28000000 7c070e02 ...(...x...(...| 009184e0: 28000000 70040e02 28000000 74040e02 ...(...p...(...t 009184f0: 28000000 78040e02 28000000 7c040e02 ...(...x...(...| 00918500: 28000000 00081b02 030039a1 0c081b02 ...(.....9...... 00918510: 1f001f00 10081b02 1f001f00 3c081b02 ...............< 00918520: 16021c42 40081b02 7a017b01 48081b02 B......@.{.z...H 00918530: 4c4e4a4b 50081b02 34333f3f 1c081b02 KJNL...P??34.... 00918540: 33333333 20081b02 33333333 24081b02 3333... 3333...$ 00918550: 33333333 28081b02 33333333 b8081b02 3333...(3333.... 00918560: 00080000 04001b02 25000200 08001b02 ...........%.... 00918570: 30303300 0c001b02 13536b67 10001b02 .300....gkS..... 00918580: 638b6eb6 14001b02 db00ff01 18001b02 .n.c............ 00918590: 40170000 1c001b02 00800000 2c001b02 ...@..........., 009185a0: d2260000 30001b02 23106b00 40001b02 ..&....0.k.#...@ 009185b0: 27000000 00001b02 00001984 1c001b02 ...'............ 009185c0: 32800004 1c001b02 33800000 1c001b02 ...2.......3.... [ETC....] MX6SOLO SABREAUTO U-Boot >‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Let's check the persistent bit (i.MX6S or DL) PERSIST_SECONDARY_BOOT, reflecting from which image you boot: MX6SOLO SABREAUTO U-Boot > md 0x20D8044 1 020d8044: 40000000    ...@ MX6SOLO SABREAUTO U-Boot >‍‍‍‍‍‍‍‍ Bit 30 is 0, meaning you boot from first image Let's erase one boot image to see it it still boot (you have 2 boot images) MX6SOLO SABREAUTO U-Boot > nand erase 0x400000 0x512 NAND erase: device 0 offset 0x400000, size 0x512 Warning: Erase size 0x00000512 smaller than one erase block 0x00080000 Erasing 0x00080000 instead Erasing at 0x400000 -- 100% complete. OK MX6SOLO SABREAUTO U-Boot >‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Presss the reset button of your board to see if the board still start. If you read the PERSIST_SECONDARY_BOOT persistent bit, you'll see you boot from the second image as bit 30 is active: MX6SOLO SABREAUTO U-Boot > md 0x20D8044 1 020d8044: 40000000    ...@ MX6SOLO SABREAUTO U-Boot >‍‍‍‍‍‍‍‍ If you erase the second image (address 0xa00000, board will not boot as you only have 2 images). What you can do thenis read your FCB (flash configuration) with the following commands in u-boot prompt (sometimes the first read fails! so try again): WARNING: this was for a 2009 u-boot, in newer version (2016 for instance) you have to do a "nand dump" otherwise it will return an error (FAIL -74), see [Uboot] Nand read from offset xxx failed -74  MX6SOLO SABREAUTO U-Boot > nand read 0x918000 0x40000 0x800 NAND read: device 0 offset 0x40000, size 0x800 NAND read from offset 40000 failed -74 0 bytes read: ERROR MX6SOLO SABREAUTO U-Boot > nand read 0x918000 0x40000 0x800 NAND read: device 0 offset 0x40000, size 0x800 2048 bytes read: OK MX6SOLO SABREAUTO U-Boot > md 0x918000 0x100 00918000: fc000000 4346ffff 00002042 3c500100 ......FCB ....P< 00918010: 00000619 10000000 10e00000 00800000 ................ 00918020: 00000000 00000000 00000000 00080000 ................ 00918030: 02000000 02000000 00080000 000a0000 ................ 00918040: 00070000 00000000 00000000 00000000 ................ 00918050: 00000000 00000000 00000000 00000000 ................ 00918060: 00000000 00000000 04000000 0a000000 ................ 00918070: 002a0000 002a0000 02000000 0f400000 ..*...*.......@. 00918080: 00000000 10000000 00000000 00000000 ................ 00918090: 00000000 00000000 00000000 00000000 ................ 009180a0: 00000000 00000000 00000000 00000000 ................ 009180b0: 00000000 00000000 00000000 00000000 ................ 009180c0: 00000000 00000000 00000000 00000000 ................ 009180d0: 00000000 00000000 00000000 00000000 ................ 009180e0: 00000000 00000000 00000000 00000000 ................ 009180f0: 00000000 00000000 00000000 00000000 ................ 00918100: 00000000 00000000 00000000 00000000 ................ 00918110: 00000000 00000000 00000000 00000000 ................ 00918120: 00000000 00000000 00000000 00000000 ................ 00918130: 00000000 00000000 00000000 00000000 ................ 00918140: 00000000 00000000 00000000 00000000 ................ 00918150: 00000000 00000000 00000000 00000000 ................ 00918160: 00000000 00000000 00000000 00000000 ................ 00918170: 00000000 00000000 00000000 00000000 ................ 00918180: 00000000 00000000 00000000 00000000 ................ 00918190: 00000000 00000000 00000000 00000000 ................ 009181a0: 00000000 00000000 00000000 00000000 ................ 009181b0: 00000000 00000000 00000000 00000000 ................ 009181c0: 00000000 00000000 00000000 00000000 ................ 009181d0: 00000000 00000000 00000000 00000000 ................ 009181e0: 00000000 00000000 00000000 00000000 ................ 009181f0: 00000000 00000000 00000000 00000000 ................ 00918200: 00001a1c 0000000e 00000000 00000000 ................ 00918210: 00000000 00000019 00001600 00001600 ................ 00918220: 00000019 0000000f 00000019 00000000 ................ 00918230: 00000000 00000000 00000000 00000000 ................ 00918240: 00000000 00000000 00000000 00000000 ................ 00918250: 00001300 00000f00 00000008 00000008 ................ 00918260: 00001600 00000015 00000000 00001a00 ................ 00918270: 00000000 00000000 00000000 00000000 ................ 00918280: 00000000 00000000 00000000 00000000 ................ 00918290: 00000000 00000000 00000000 00000000 ................ 009182a0: 00000000 00000000 00000000 00000000 ................ 009182b0: 00000000 00000000 00000000 00000000 ................ 009182c0: 00000000 00000000 00000000 00000000 ................ 009182d0: 00000000 00000000 00000000 00000000 ................ 009182e0: 00000000 00000000 00000000 00000000 ................ 009182f0: 00000000 00000000 00000000 00000000 ................ 00918300: 00000000 00000000 00000000 00000000 ................ 00918310: 00000000 00000000 00000000 00000000 ................ 00918320: 00000000 00000000 00000000 00000000 ................ 00918330: 00000000 00000000 00000000 00000000 ................ 00918340: 00000000 00000000 00000000 00000000 ................ 00918350: 00000000 00000000 00000000 00000000 ................ 00918360: 00000000 00000000 00000000 00000000 ................ 00918370: 00000000 00000000 00000000 00000000 ................ 00918380: 00000000 00000000 00000000 00000000 ................ 00918390: 00000000 00000000 00000000 00000000 ................ 009183a0: 00000000 00000000 00000000 00000000 ................ 009183b0: 00000000 00000000 00000000 00000000 ................ 009183c0: 00000000 00000000 00000000 00000000 ................ 009183d0: 00000000 00000000 00000000 00000000 ................ 009183e0: 00000000 00000000 00000000 00000000 ................ 009183f0: 00000000 00000000 00000000 00000000 ................ MX6SOLO SABREAUTO U-Boot >‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ If you read the addresses 0x000000, 0x40000, 0x80000, 0xc0000, 0x100000, 0x140000 or 0x180000 or 0x1c0000 you'll have a copy of the FCB in OCRAM (internal RAM) and then read the OCRAM. You can now try that the replication is working. Thus try to erase FCBs (in my case, with Micron MT29F16G08ABABAWP the minimum I can erase is 2 FCBs due to sector size of 0x80000, check it on your side), for u-boot after 2009 use "nand dump", see https://community.nxp.com/message/885233  : MX6SOLO SABREAUTO U-Boot > nand erase 0x0 0x512 NAND erase: device 0 offset 0x0, size 0x512 Warning: Erase size 0x00000512 smaller than one erase block 0x00080000 Erasing 0x00080000 instead Erasing at 0x0 -- 100% complete. OK MX6SOLO SABREAUTO U-Boot > nand erase 0x80000 0x512 NAND erase: device 0 offset 0x80000, size 0x512 Warning: Erase size 0x00000512 smaller than one erase block 0x00080000 Erasing 0x00080000 instead Erasing at 0x80000 -- 100% complete. OK MX6SOLO SABREAUTO U-Boot > nand erase 0x100000 0x512 NAND erase: device 0 offset 0x100000, size 0x512 Warning: Erase size 0x00000512 smaller than one erase block 0x00080000 Erasing 0x00080000 instead Erasing at 0x100000 -- 100% complete. OK MX6SOLO SABREAUTO U-Boot >‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ You have erase 6 FCB. If you press reset, you normallystill can boot the device (checkswitch S1 is configured like that: 0001100000). You can also read the bad block table. In enclosed "mx6Solo_RAW_NAND_SABRE_AI_programming_verbose.txt" you have addresses of the DBBT: 0x200000, 0x240000, 0x280000, 0x2c0000, 0x300000, 0x340000, 0x380000 and 0x3c0000: -------------- Start to write the [ DBBT ] ----- mtd: erasing @0:0x200000-0x280000 mtd: Writing DBBT0 [ @0:0x200000 ] (1000) * mtd: Writing DBBT1 [ @0:0x240000 ] (1000) * mtd: erasing @0:0x280000-0x300000 mtd: Writing DBBT2 [ @0:0x280000 ] (1000) * mtd: Writing DBBT3 [ @0:0x2c0000 ] (1000) * mtd: erasing mtd: Writing DBBT4 [ @0:0x300000 ] (1000) * mtd: Writing DBBT5 [ @0:0x340000 ] (1000) * mtd: erasing @0:0x380000-0x400000 mtd: Writing DBBT6 [ @0:0x380000 ] (1000) * mtd: Writing DBBT7 [ @0:0x3c0000 ] (1000) * mtd_commit_bcb(DBBT): status 0‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ now read a DBBT in u-boot (as already mentionned, sometimes nand read failed, so try again!): MX6SOLO SABREAUTO U-Boot > nand read 0x918000 0x280000 0x800 NAND read: device 0 offset 0x280000, size 0x800 2048 bytes read: OK MX6SOLO SABREAUTO U-Boot > md 0x918000 0x80 00918000: 00000000 54424244 01000000 00000000 ....DBBT........ 00918010: 00000000 00000000 00000000 00000000 ................ 00918020: 00000000 00000000 00000000 00000000 ................ 00918030: 00000000 00000000 00000000 00000000 ................ 00918040: 00000000 00000000 00000000 00000000 ................ 00918050: 00000000 00000000 00000000 00000000 ................ 00918060: 00000000 00000000 00000000 00000000 ................ 00918070: 00000000 00000000 00000000 00000000 ................ 00918080: 00000000 00000000 00000000 00000000 ................ 00918090: 00000000 00000000 00000000 00000000 ................ 009180a0: 00000000 00000000 00000000 00000000 ................ 009180b0: 00000000 00000000 00000000 00000000 ................ 009180c0: 00000000 00000000 00000000 00000000 ................ 009180d0: 00000000 00000000 00000000 00000000 ................ 009180e0: 00000000 00000000 00000000 00000000 ................ 009180f0: 00000000 00000000 00000000 00000000 ................ 00918100: 00000000 00000000 00000000 00000000 ................ 00918110: 00000000 00000000 00000000 00000000 ................ 00918120: 00000000 00000000 00000000 00000000 ................ 00918130: 00000000 00000000 00000000 00000000 ................ 00918140: 00000000 00000000 00000000 00000000 ................ 00918150: 00000000 00000000 00000000 00000000 ................ 00918160: 00000000 00000000 00000000 00000000 ................ 00918170: 00000000 00000000 00000000 00000000 ................ 00918180: 00000000 00000000 00000000 00000000 ................ 00918190: 00000000 00000000 00000000 00000000 ................ 009181a0: 00000000 00000000 00000000 00000000 ................ 009181b0: 00000000 00000000 00000000 00000000 ................ 009181c0: 00000000 00000000 00000000 00000000 ................ 009181d0: 00000000 00000000 00000000 00000000 ................ 009181e0: 00000000 00000000 00000000 00000000 ................ 009181f0: 00000000 00000000 00000000 00000000 ................ MX6SOLO SABREAUTO U-Boot >‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Here I have no bad block (it is a SLC RAW NAND flash..). To be sure I have effectively erased 6 FCB, I will erase the 2 last one... thus I will not boot as all FCB tables will be erased(remove the usb cable otherwise mfgtool will restart): MX6SOLO SABREAUTO U-Boot > nand erase 0x180000 0x512 NAND erase: device 0 offset 0x180000, size 0x512 Warning: Erase size 0x00000512 smaller than one erase block 0x00080000 Erasing 0x00080000 instead Erasing at 0x180000 -- 100% complete. OK MX6SOLO SABREAUTO U-Boot >‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Reset the board... and it will not start as you have erased all the 8 FCB tables... you have to reprogram your board if you want to start again.
View full article
The MYC-C8MMX CPU Moduleis designed by MYIR, which is an ARM embedded System-on-Module (SoM) based on NXP’ i.MX 8M Mini Quad Application Processor. The MYD-C8MMX development board is built around the MYC-C8MMX CPU Module, it is a complete evaluation module for your prototype and reference design. It is capable of running Linux and Android OS and provided with plenty of software resources. Typical applications are for Industry Control, Smart City, Smart Home, HMI, Internet of Things (IoT), etc. Let’s see a video introduction of the MYD-C8MMX development board. https://youtu.be/FL_CZiSMYsM The MYC-C8MMX CPU Moduleis using the MIMX8MM6CVTKZAA (MIMX8MM6DVTLZAA) processor chip which is among the NXP i.MX 8M Mini family and combines advanced 14LPC FinFET process technology to provide more speed and improved power efficiency. It has a quad Cortex-A53 core which operates at speeds of up to 1.6 (1.8) GHz. It also has a general-purpose Cortex-M4 400 MHz core processor for low-power processing. Some parameters and target applications of the processor chip are listed below for reference. Parameter Value Core: Number of cores (SPEC) 4 Core Type Arm Cortex-A53 Operating Frequency [Max] (MHz) 1600 (MIMX8MM6CVTKZAA)/1800 (MIMX8MM6DVTLZAA) L2 Cache (Max) (KB) 512 Co-Processor Type Arm Cortex-M4F Co-Processor Frequency (MAX) (MHz) 400 External Memory Supported DDR3L SDRAM, DDR4 SDRAM, ECC, LPDDR4 DRAM, NAND FLASH, NOR FLASH, QSPI GPU 2D / GPU 3D 1x shader, Vivante GC320, Vivante GCNanoUltra MIMX8MM6CVTKZAA (MIMX8MM6DVTLZAA) processor The chip only has MIPI-DSI and MIPI-CSI interfaces and no HDMI or other display interfaces. It can support wide working temperature range from -40 to 105 Celsius degree. MYIR’s MYC-C8MMX CPU Module can support working temperature from -40 to 85 Celsius degree. Parameter Value HW Video Encoder / Decoder HD1080p60 H.264, HD1080p60 H.265 Video/Display features MIPI-CSI, MIPI-DSI PCIe PCIe 2.0 x 1 Audio Specific Modules 8-ch PDM input, SAI USB Controllers 2 Serial Communication 1 x PCIe 2.0,3 x SPI,4 x I²C,4 x UART Junction Temperature (℃) -40 to 105 (MIMX8MM6CVTKZAA), 0 to 95 (MIMX8MM6DVTLZAA) MIMX8MM6CVTKZAA (MIMX8MM6DVTLZAA) processor Target Applications of i.MX 8M Mini Processors Automotive Smart City Heating Ventilation, and Air Conditioning (HVAC) Automatic Vehicle Identification Motorcycle Engine Control Unit (ECU) and Small Engine Control Fleet Management   Inventory and Supply Chain Management Industrial Public Address Systems Air Conditioning (AC) Transport Ticketing Building Safety   Building Security Smart Home Digital Signage Audio/Video (AV) Receivers Energy Gateway Gaming Console Heat Metering Home Control Panel Hospital Admission Machine Home Security & Surveillance Image Analytics Home Sensor Industrial Control In-Home Energy Display Industrial HMI Major Home Appliances Machine Visual Inspection Robotic Appliance Smart Lighting Set Top Boxes Smart Power Socket and Light Switch Small and Medium Appliances Two-way Video Conferencing Smart Speaker Vision, Advanced Sensing and Processing Board Soundbar   Surround Sound and Sound Bars Mobile Wireless or Networked Speakers Cable   Hearables Technologies Input Device (Mouse, Pen, Keyboard) Voice Assistants Smart Watch Voice Control Wireless Charging Pad   Wristband   The MYC-C8MMX CPU Module is a minimum system with PMIC, CPU, RAM (DDR4), Flash (eMMC, SPI Flash) and clock, plus an Ethernet PHY chip. A number of peripheral and IO signals are access through two 0.8mm pitch 100-pin board-to-board expansion connectors.                           MYC-C8MMX CPU Module Top-view                                         MYC-C8MMX CPU Module Bottom-view The MYD-C8MMX base board has mainly extended four parts: 1. Audio interface: added audio chip to extend Audio input and output interfaces 2. External power supply part: added one DC-DC power chip 3. Added one USB hub chip to extend 4 USB from the SoC USB interface, separately used for 4G LTE, two USB Host and one USB on expansion header. 4. Extend RTC module through I2C interface Many other peripheral interfaces are brought out for user extension.                                                    MYD-C8MMX Function Block Diagram                                                            MYD-C8MMX Interface Diagram Among so many interfaces, Backlight, LVDS LCD and MIPI interface are relative to display function. The Backlight interface has 6 pins including two power signals, two GND and two GPIO (one is enabled terminal to control the backlight power and another is PWM to control the brightness of backlight.) The two GPIO control terminals are from the GPIO1_01 and 08 of the i.MX 8M Mini. The LVDS LCD and MIPI interface, total 3 interfaces are for display. But actually i.MX 8M Mini only has one MIPI DSI interface. The other two LVDS interfaces are switched from DSI through one DS12LVDS bridge chip, one is single link LVDS and another is dual link LVDS. So, we can only select MIPI DSI display or LVDS display. Also, we can only select single link LVDS or dual link LVDS. MYIR offers optional LVDS based 7-inch LCD Module MY-LVDS070C including capacitive touch screen to work with the MYD-C8MMX board. The display resolution is up to 1024 by 600 pixels.                            MY-LVDS070C 7-inch LCD Module with Capacitive Touch Screen The MYD-C8MMX has one 2.0mm pitch 2*15-pin male expansion header. PDM and SAI are audio relative interfaces which are brought out from the expansion header.
View full article
This the document for SUSPEND and WAKE-UP in IMX8QM-MEK platform Wake up done by following, M4  debug UART A53 debug UART Power Key Source: imx-p9.0.0_2.1.1-auto-ga CONFIGURATION          Disable the default wake-up - RTC Timer (Patch - Disable_auto_wakeup.diff) SUSPEND      1. Command  Line,             # echo mem > /sys/power/state      2. Dumpsys Command                  # dumpsys activity service com.android.car inject-vhal-event 0x11410a00 4,2 WAKE-UP     1. BUTTON          By pressing the power-key SW3 (0.5s)      2. DEBUG UART          Enable debug UART wake-up          # cat ./sys/devices/platform/5a060000.serial/tty/ttyLP0/power/wakeup          disabled          # echo enabled  > ./sys/devices/platform/5a060000.serial/tty/ttyLP0/power/wakeup          TO WAKEUP                   Press the ENTER Key 2 times 3. M4 UART WAKEUP                        Apply the RPMSG patch (L4.14.98.diff)                                        # cat./sys/devices/platform/5a070000.serial/tty/ttyLP1/power/wakeup          disabled          # echo enabled > ./sys/devices/platform/5a070000.serial/tty/ttyLP1/power/wakeup Type some input in M4 Cosole               
View full article
Measuring 60mm by 49mm, the MYC-C8MMX CPU Module is a high-performance and cost-effective ARM SoM powered by i.MX 8M Mini which is NXP's first embedded multi-core heterogeneous applications processors built using advanced 14LPC FinFET process technology. The MYC-C8MMX CPU Module provides an outstanding embedded solution for Home and Building Control, IOV, Industrial and Medical Instruments, Human Machine Interface (HMI) and more other general purpose industrial and IoT applications which require optimized power consumption while maintaining high-performance. It is a minimum system integrated with CPU, 2GB DDR4, 8GB eMMC, 32MB QSPI Flash, GigE PHY and PMIC. All controller signals are brought out through two 0.8mm pitch 100-pin Expansion Connectors. It is capable of running Linux and Android OS and provided with plenty of software resources.                         MYC-C8MMX CPU Module Top-view                                         MYC-C8MMX CPU Module Bottom-view   MYIR offers MYD-C8MMX development board for evaluating the MYC-C8MMX CPU Module, the base board has taken great media capabilities of the i.MX 8M Mini processor to provide MIPI-DSI, MIPI-CSI, LVDS interfaces and Audio In/Out ports. It also has strong communication connectivity with 2 x USB 2.0 Host ports and 1 x Micro USB 2.0 Host/Device port, Gigabit Ethernet, MicroSD card slot, USB based Mini PCIe interface for 4G LTE Module, WiFi/Bluetooth and NVMe PCIe M.2 2280 SSD Interface. MYIR can offer design services to help customize the base board according to customers’ requirements.                                                    MYD-C8MMX Development Board Top-view                                                     MYD-C8MMX Development Board Bottom-view   MYIR offers commercial and industrial grades options for CPU Modules. More information can be found at: http://www.myirtech.com/list.asp?id=617
View full article
The documentation is the V2 version has added some FAQs for development based on NXP's i.MX 6UL/6ULL ARM Cortex-A7 processors. MYIR provides a series of i.MX 6UL/6ULL based products including SoM, SBC, development board and HMI display panel.   MYS-6ULX | NXP i.MX 6UL / 6ULL SBC Board for IoT and Industry Applications  MYC-Y6ULX CPU Module | NXP i.MX 6UL, i.MX 6ULL SOM | ARM Cortex-A7 Processor    MYD-Y6ULX | NXP i.MX 6UL, i.MX 6ULL Development Board / SOM, ARM Cortex-A7 Processor MYD-Y6ULX-HMI Development Board | NXP i.MX 6UL/6ULL Board for HMI Applications    MYD-Y6ULX-CHMI Display Panel | NXP i.MX 6UL/6ULL based 7-inch HMI Solution MYIR is pleased to share the experience with more developers. 
View full article
Below are the patches to support SDIO-UART 8987 M2 module on mek_8q M2 port. After applying the patches, PCIe chip can't be recognized on M2 port. Revert the patches if want to use PCIe chip. Patches are from Andy Duan. --- a/board/freescale/imx8qm_mek/imx8qm_mek.c +++ b/board/freescale/imx8qm_mek/imx8qm_mek.c @@ -373,6 +373,7 @@ int board_init(void) #if defined(CONFIG_USB) && defined(CONFIG_USB_TCPC)         setup_typec(); #endif +       sc_pm_set_resource_power_mode(-1, SC_R_BOARD_R3, SC_PM_PW_MODE_ON); #ifdef CONFIG_SNVS_SEC_SC_AUTO         { --- a/arch/arm64/boot/dts/freescale/imx8qm-mek.dts +++ b/arch/arm64/boot/dts/freescale/imx8qm-mek.dts @@ -151,6 +151,11 @@     };   + usdhc3_pwrseq: usdhc3_pwrseq { +  compatible = "mmc-pwrseq-simple"; +  reset-gpios = <&lsio_gpio1 13 GPIO_ACTIVE_LOW>; + }; +   epdev_on: fixedregulator@100 {    compatible = "regulator-fixed";    pinctrl-names = "default", "sleep"; @@ -159,8 +164,6 @@    regulator-min-microvolt = <3300000>;    regulator-max-microvolt = <3300000>;    regulator-name = "epdev_on"; -  gpio = <&lsio_gpio1 13 0>; -  enable-active-high;   };     reg_fec2_supply: fec2_nvcc { @@ -1036,6 +1039,22 @@   status = "okay";  };   +&usdhc3 { +        pinctrl-names = "default", "state_100mhz", "state_200mhz"; +        pinctrl-0 = <&pinctrl_usdhc3>,<&pinctrl_usdhc3_gpio>; +        pinctrl-1 = <&pinctrl_usdhc3>,<&pinctrl_usdhc3_gpio>; +        pinctrl-2 = <&pinctrl_usdhc3>,<&pinctrl_usdhc3_gpio>; +        bus-width = <4>; + pinctrl-assert-gpios = <&lsio_gpio4 9 GPIO_ACTIVE_HIGH>; + pinctrl-assert-gpios = <&lsio_gpio4 10 GPIO_ACTIVE_HIGH>; + mmc-pwrseq = <&usdhc3_pwrseq>; + pm-ignore-notify; + keep-power-in-suspend; + non-removable; + cap-power-off-card; +        status = "okay"; +}; +  &i2c0 {   #address-cells = <1>;   #size-cells = <0>; @@ -1540,7 +1559,6 @@    fsl,pins = <     IMX8QM_PCIE_CTRL0_WAKE_B_LSIO_GPIO4_IO28  0x04000021     IMX8QM_PCIE_CTRL0_PERST_B_LSIO_GPIO4_IO29  0x06000021 -   IMX8QM_USDHC2_RESET_B_LSIO_GPIO4_IO09   0x06000021    >;   };   @@ -1618,7 +1636,26 @@     IMX8QM_USDHC1_DATA1_CONN_USDHC1_DATA1   0x00000021     IMX8QM_USDHC1_DATA2_CONN_USDHC1_DATA2   0x00000021     IMX8QM_USDHC1_DATA3_CONN_USDHC1_DATA3   0x00000021 -   IMX8QM_USDHC1_VSELECT_CONN_USDHC1_VSELECT  0x00000021 +   IMX8QM_USDHC1_VSELECT_CONN_USDHC1_VSELECT               0x00000021 +  >; + }; + + pinctrl_usdhc3_gpio: usdhc3grpgpio { +  fsl,pins = < +   IMX8QM_USDHC2_VSELECT_LSIO_GPIO4_IO10   0x00000021 +   IMX8QM_LVDS1_I2C0_SDA_LSIO_GPIO1_IO13   0x06000021 +   IMX8QM_USDHC2_RESET_B_LSIO_GPIO4_IO09   0x06000021 +  >; + }; + + pinctrl_usdhc3: usdhc3grp { +  fsl,pins = < +   IMX8QM_USDHC2_CLK_CONN_USDHC2_CLK         0x06000041 +   IMX8QM_USDHC2_CMD_CONN_USDHC2_CMD         0x00000021 +   IMX8QM_USDHC2_DATA0_CONN_USDHC2_DATA0     0x00000021 +   IMX8QM_USDHC2_DATA1_CONN_USDHC2_DATA1     0x00000021 +   IMX8QM_USDHC2_DATA2_CONN_USDHC2_DATA2     0x00000021 +   IMX8QM_USDHC2_DATA3_CONN_USDHC2_DATA3     0x00000021    >;   };   @@ -1680,13 +1717,11 @@     pinctrl_wlreg_on: wlregongrp{    fsl,pins = < -   IMX8QM_LVDS1_I2C0_SDA_LSIO_GPIO1_IO13  0x06000000    >;   };     pinctrl_wlreg_on_sleep: wlregon_sleepgrp{    fsl,pins = < -   IMX8QM_LVDS1_I2C0_SDA_LSIO_GPIO1_IO13  0x07800000    >;   };  
View full article
This is ITE MIPI to HDMI/IT6161 video bridge already merge/verified with i.Mx8 series processor. attached is IT6161 MINISAS card user manuel and reference circuits.@
View full article
This FAQ is based on MYIR's i.MX6UL&6ULL products but also can be applied on products of other vendors. MYIR provides a series of i.MX 6UL/6ULL based products including SoM, SBC, development board and HMI display panel. MYD-Y6ULX-CHMI | 7-inch HMI Display Solution based on NXP i.MX 6UL/6ULL-Welcome to MYIR  MYS-6ULX | NXP i.MX 6UL / 6ULL SBC Board for IoT and Industry Applications-Welcome to MYIR  MYC-Y6ULX CPU Module | NXP i.MX 6UL, i.MX 6ULL SOM | ARM Cortex-A7 Processor-Welcome to MYIR   MYD-Y6ULX | NXP i.MX 6UL, i.MX 6ULL Development Board / SOM, ARM Cortex-A7 Processor-Welcome to MYIR  MYD-Y6ULX-HMI Development Board | NXP i.MX 6UL/6ULL Board for HMI Applications-Welcome to MYIR  MYIR is pleased to share the experience with more developers. 
View full article
iWave Systems, AI/ML demo shows a low power smart door running eIQ heterogeneously on NXP i.MX 8M Mini Development kit. The demo application is built around the Django framework running on the board. In addition to face recognition, the MPUs are able to run a Django server to manage the user’s database, a QT5 application for the graphical interface, and perform training on the edge.
View full article
NXP i.MX8M-Mini CPU, quad-core Cortex-A53 Up-to 4GB RAM and 128GB eMMC LTE modem, WiFi 802.11ac, Bluetooth 5.0 2x Ethernet, 3x USB2, RS485/RS232, CAN-FD Custom I/O expansion boards Fanless design in aluminum, rugged housing Designed for reliability and 24/7 operation Wide temperature range of -40C to 80C Wide input voltage range of 8V to 36V Debian Linux, Yocto Project and mainline kernel Support for Docker and Microsoft Azure IoT   IOT-GATE-iMX8 is built around the NXP i.MX8M Mini System-on-Chip, featuring an advanced ARM Cortex-A53 CPU. The SoC is supplemented with up-to 4GB LPDDR4 and 128GB of eMMC storage.   Featuring dual Ethernet, CAN-FD, LTE modem, 802.11ac WiFi and Bluetooth 5.0, IOT-GATE-iMX8 is a highly versatile platform for industrial control, networking, communications and IoT applications. Fanless rugged enclosure design, wide range DC input of 8V to 36V and industrial temperature range of -40C to 80C make IOT-GATE-iMX8 an ideal solution for industrial installations and harsh environments.  IOT-GATE-iMX8 is provided with ready-to-run Debian Linux and full Linux Board Support Package. IOT-GATE Linux packages support Docker and Microsoft Azure IoT.   IOT-GATE-iMX8 spec IOT-GATE-iMX8 evaluation kit IOT-GATE-iMX8 pricing
View full article