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

NXP i.MX7 CPU, dual-core Cortex-A7 1GHz Up to 2GB DDR3 and 32GB eMMC 3G/LTE modem, WiFi 802.11a/b/g/n, BT 4.1 2x 1000Mbps Ethernet, 4x USB2, RS485, RS232 Support for PoE powered mode Fanless design in aluminum, rugged housing Miniature size – 10.8 x 8.3 x 2.4 cm Designed for reliability and 24/7 operation Wide temperature range of -40C to 85C Mainline Linux kernel and full Linux BPS IOT-GATE-iMX7 is built around the NXP i.MX7 System-on-Chip featuring an advanced ARM Cortex-A7 CPU coupled with a dedicated real-time ARM Cortex-M4 MCU. The SoC is supplemented with up-to 2GB DDR3 and 32GB of on-board eMMC storage.   Featuring a wide range of embedded interfaces, IOT-GATE-iMX7 is a versatile platform for industrial automation and control systems. Dual Gbit Ethernet, 3G/LTE modem, dual-band 802.11a/b/g/n WiFi and Bluetooth 4.1 make IOT-GATE-iMX7 an excellent solution for networking, communications and IoT applications.   IOT-GATE-iMX7 is provided with a full Board Support Package and ready-to-run images for the Linux operating system. The IOT-GATE-iMX7 BSP includes Linux kernel 4.1.15, Yocto Project file-system and U-Boot boot-loader. In addition, CompuLab will support IOT-GATE-iMX7 with mainline Linux and upstream Yocto Project. IOT-GATE-iMX7 spec IOT-GATE-iMX7 evaluation kit IOT-GATE-iMX7 pricing

Introduction i.MX6SoloX and i.MX7D SoC contain embedded Cortex-M4 core. In a common use-case, this core runs a firmware loaded by u-boot bootloader. If you however want to debug your application for the Cortex-M4 core, you may need to reload the firmware in the secondary core without restarting Linux running on the Cortex-A core. For this reason, a tool was created: imx-m4fwloader. The project is released as open source under GPL-2.0 licence here: GitHub - NXPmicro/imx-m4fwloader: Tool for loading firmware to M4 core on i.MX6SX and 7D  I hope this tool will help to bring up faster your application for i.MX6SoloX and i.MX7D SoC! How to use this Either use the pre-built version Or use the environment provided to you by Yocto: For example: source /opt/poky/1.8/environment-setup-cortexa9hf-vfp-neon-poky-linux-gnueabi $CC m4fwloader.c -o m4fwloader You get m4fwloader binary... Then you need to build your M4 application and link it to some address. (e.g 0x00910000, try: https://github.com/EmbeddedRPC/erpc-imx-demos/tree/master/MCU/example_rpmsg) Load it using m4fwloader: ./m4fwloader myapp.bin 0x00910000 Optionally use --verbose parameter to see what is written to each registers Warning: Use this tool for debugging only, since it accesses directly the registers from the user space and requires therefore root priviledges! You have been warned... 🙂 Optionally, you can trigger an interrupt using message unit (MU) to the M4 core to get RPMsg started - this is normally done by Linux Kernel during startup: ./m4fwloader kick 0 Whole usage is here: m4fwloader [filename.bin] [0xLOADADDR] [--verbose] # loads new firmware or: m4fwloader stop # holds the auxiliary core in reset or: m4fwloader start # releases the auxiliary core from reset or: m4fwloader kick [n] # triggers interrupt on RPMsg virtqueue n

Hi, check out this video that demonstrates software making use of power savings capabilities on the i.MX28:  http://go.mentor.com/low-power

Hi NXP expert : Deaufult iMX8M apply 3GB DRAM density with the system, How to modify DRAM configration that could cutdowm density to 1GB DRAM ? 

Timesys can help you build your custom BSP/SDK in minutes with FREE LinuxLink web edition   Use LinuxLink Web Edition to build a custom BSP/SDK for your board within a few minutes. Start your application development with the free version of our Eclipse-based TimeStorm IDE. Browse a sub-set of our vast documentation library. Get notified via email of any updates to the Linux kernel and middleware/packages for your BSP/SDK   Click here to start building your custom BSP/SDK.  

With last LTIB - BSP release there was an interesting and very usefull document (attached here) """""""""""""""""""""""""""""""""""""""""""" i.MX 6Dual/6Quad BSP Porting Guide Document Number: IMX6DQBSPPG Rev. L3.0.35_1.1.0, 01/2013 """""""""""""""""""""""""""""""""""""""""""" In this document there were the most used needed steps to port the BSP from a reference board (i will take as example the IMX6q sabresd) to a Custom board. Infact the usual project path , is starting from a reference board , but a t the end i need to use a custom board (for costs , space and any other reason). So the Idea is o make a new document to do the same on the new Yocto enviroment. Infact the step and the stuff to change are ecxatly the same, but they are to be done in different way. When you want to make your custom board what can be different from a reference one: 1) DDR memory 2) IO usage 3) on board peripheral 4) boot source I think these are the main issue that could change from a board to another one (with the same processor Imx6q). Following the "Yocto Project best practice guide" we need to create a new "layer" where we can fit the customized thing: uboot, dts, drivers for pheriperal, maybe customized kernel .... So this document is intended to be a starting point where customer and freescale expert can work togheter to make this "aplication note " that is really the final step for every project based on imx6Q Yocto Project development. Omar *************************************************************************************************************************************************************************************************************************************** Following I will try to examine the single step that needs to be configured in every board. First a brief summary then each step will be detailed with files and paths , and example modification. I will use as example the board IMX6QsabreSD. So all the path will be referred to that board. *************************************************************************************************************************************************************************************************************************************** I)                                                                                                                Porting Bootloader *************************************************************************************************************************************************************************************************************************************** 1) They first program loaded and executed from your boot source (NAND, emmc, SD etc..) is the bootloader. In our case u-boot. this program perform some basic initialization, those intializations are related to the board. But the very first thing is DDR initialization, this mean to inizialize IOMUX and DDR controller registers (Timing geometry etcc...). This initialization is done in the DCD part of the uboot image. the once we initialized the DDR the bootloader can work, than it will have to configure the IOMUX to match the peripheral used on chip and on board. And then of course it will have to load the driver (at least one UART for consolle and ethernet driver) it needs. So FIRST thing to customize for your board is the bootloader. Using a base directory the git of u-boot the file that contain the DCD is: board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg the other important file is the board/freescale/mx6sabresd/mx6sabresd.c this second file contain several board related definition, first of all, the IOMUX configuration for the pins of IMX6Q used for soc peripheral a third important file is the include one here there are several important define such as mem size. include/configs/mx6sabresd.h include/configs/mx6sabre_common.h So you need to make a copy of those files (in the new board dir, or in the include/configs for .h files) renaming them of course with the name of your custom board. Then you need also to add the new board to the Makefiles and source tree , as described following: (take also as a reference he chapter 1.2 and 1.3 of the attached document and this link http://git.denx.de/?p=u-boot.git;a=blob_plain;f=README;hb=HEAD). 1. Add a new configuration option for your board to the toplevel  "boards.cfg" file, using the existing entries as examples.  Follow the instructions there to keep the boards in order. 2. Create a new directory to hold your board specific code. Add any files you need. In your board directory, you will need at least the "Makefile", a "<board>.c" 3. Create a new configuration file "include/configs/<board>.h" for  your board 4. Debug and solve any problems that might arise. At this point if we did all the modification we need to u-boot we have to create our fsl-myboard layer to add our "patch" to the u-boot tree. those patched u-boot will be compiled and deployed just for the new MACHINE (our custom board). *************************************************************************************************************************************************************************************************************************************** II)                                                                                                                Creating DTS tree for kernel *************************************************************************************************************************************************************************************************************************************** 1)Then you need to create the DTS files for your board as well, those files are a description of your board (including) SOC , mem etc etc... used by the kernel. those files are in the kernel tree in arch/arm/boot/dts. Take a look http://events.linuxfoundation.org/sites/events/files/slides/petazzoni-device-tree-dummies.pdf  this is a good starting point. Another good reference is: Device Tree - eLinux.org , here you can find a lot of link and reference to a more deep understanding. The official wiki:http://www.devicetree.org/Main_Page And interesting: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree In our example the reference dts will be of course the imx6q-sabresd.dts(in the kernel tree source path /arch/arm/boot/dts), this file include and refer other "dts" files that we will see . Well the starting point of this dts tree is, in this example, the imx6q-sabresd.dts, it recalls other files: imx6q-sabresd.dts ---------------> imx6qdl-sabresd.dtsi                           |----------------> imx6q.dtsi                                                            |--------------------> imx6q-pinfunc.h                                                            |--------------------> imx6qdl.dtsi                                                                                                   |-----------------------> skeleton.dtsi                                                                                                   |-----------------------> dt-bindings/gpio/gpio.h the file wiht the name that does not contain "sabresd" are not board related but Soc related so we can keep as is even for our custom board, so the only file we need to touch are imx6q-sabresd.dts and imx6qdl-sadresd.dtsi. As we did for u-boot porting, we will copy these files and create new ones with names as imx6q-cutomboard.dts and imx6qdl-customboard.dtsi in the same dir. Now we will examine them in detail.

iWave provides Android Lollipop and Linux 3.14 kernel BSP upgrades for its i.MX6 based products. iMX6 Board: From the launch of i.MX6 application processors, iWave Systems, a global leading SOM supplier has launched many variations of i.MX6 CPU modules and an SBC board catering to Industrial, automotive and medical applications. Complying with the Qseven R2.0 specification, the i.MX6 Q7 SOM supports industrial grade operation with 70mmx70mm size. The i.MX6 MXM SOM supports automotive grade i.MX6 CPU and the automotive specific interfaces with 314 pin MXM2 connector pinout in 85mmx85mm form factor. The recently launched i.MX6 SODIMM SOM module supports both commercial & industrial operating temperature with very compact form factor of 67.6mmx37mm. iMX6 Board Single Board Computer: Measuring 100mmx70mm, the Pico ITX size i.MX6 SBC board supports on-board connectors for all the i.MX6 interfaces with option to expand IOs through expansion connector.  All these three different form factor System on Modules and Single Board Computers are supported with different i.MX6 CPU variations such as Quad, Dual, Dual Lite & Solo. Besides this i.MX6 Qseven modules also supports i.MX6 Quad Plus and i.MX6 Dual plus CPU configurations. To enable quick prototyping of these different form factor SOMs, iWave systems supports independent development kit variation for each form factor SOMs with Linux, Android and WEC7* BSP support. These development kits help customer to save up to 60% of new product development cycle sothat the quick time to market can be achieved. All these i.MX6 products are getting Android Lollipop and Linux 3.14 kernel BSP upgrades which will be available for customers by the first quarter of 2016.

iWave Systems, Proven Partner of Freescale Semiconductor and a leading Embedded Hardware, FPGA and Software Turnkey Design Services and Solutions company, presents improved i.MX 6 Qseven Development Board RainboW-G15D that supports following  sensors: 3-Axis Accelerometer Digital e-Compass Ambient Light Sensor Altimeter/Barometer These sensors interfaced with the iMX6 processor using I2c interface for internal communication and data transfer and also possess INT (interrupt) signal to interrupt the processor about the data. The RainboW-G15D development kit with Linux 3.0.35 BSP supports these various sensors. 3-Axis Accelerometer: This Accelerometer sensor is used for Static orientation detection (Portrait/Landscape, Up/Down, Left/Right, Back/Front position identification). Motion detection for power saving (Auto-SLEEP and Auto-WAKE). Shock and vibration monitoring. Digital e-Compass: The digital e-compass sensor is used for measuring magnetic fields with an output date rates up to 80Hz (ODR). It acts as electronic Compass with accurate heading information. Location Based Services. Ambient Light Sensor: The ambient light sensor is used for measuring the light rays, it uses the photo detectors to convert the light energy into electrical energy. Altimeter/Barometer: This sensor is used for Measuring the pressure/altitude and temperature, it uses ADC to convert physical parameter into electrical. About i.MX6 Qseven Development Board: The Development Platform incorporates Qseven compatible i.MX6x SOM which is based on Freescale's iMX 6 Series 1.2GHz multimedia focused processor and Generic Q7 compatible Evaluation Board. This platform can be used for quick prototyping of any high end applications in verticals like Automotive, Industrial & Medical. Being a nano ITX form factor with 120mmx120mm size, the board is highly packed with all necessary on-board connectors to validate complete iMX6 CPU features. About i.MX6 Qseven System On Module (SOM): iW-RainboW-G15M is Freescale's i.MX6 based Qseven compatible CPU module for faster and multimedia focused applications. The module has on-board expandable 1GB DDR3 RAM, micro SD slot and optional eMMC flash. With the extreme peripheral integration, the module supports industry latest high performance interfaces such as, PCIe Gen2, Gigabit Ethernet, SATA 3.0, HDMI 1.4 and SDXC etc. About iWave Systems: iWave has been an innovator in the development of “Highly integrated, high-performance, low-power and low-cost i.MX6/i.MX50/i.MX53/i.MX51/i.MX27 SOMs”. iWave helps its customers reduce their time-to-market and development effort with its products ranging from System-On-Module to complete systems. The i.MX6 Pico ITX SBC is brought out by iWave in a record time of just 5 weeks. Furthermore, iWave’s i.MX6/i.MX50/i.MX53/i.MX51/i.MX27 SOMs have been engineered to meet the industry demanding requirements like various Embedded Computing Applications in Industrial, Medical & Automotive verticals. iWave provides full product design engineering and manufacturing services around the i.MX SOMs to help customers quickly develop innovative products and solutions. For more details: i.MX6 Q7 Development Kit | iWave Systems email: [email protected]

iWave is upgrading Android KitKat 4.4 BSP for its all variants of i.MX6 Qseven SOMs. The KitKat BSP supports following features and will be available in end of Q2 2015: i.MX6 ARM Cortex A9 Quad, Dual, Dual Lite & Solo CPU 1GB DDR3 RAM (Quad, Dual, Dual Lite CPU version)/ 512MB DDR3 (Solo CPU version) Freescale PMIC SPI NOR Flash eMMC Flash uSD slot Standard SD slot USB 2.0 Host USB 2.0 device 10/100/1000 Ethernet PCIex1 Port CAN Port LVDS display port Capacitive multi-touch PWM for backlight HDMI Port with Audio SATA (Support available only in i.MX6Q/D) Hardware Codecs (Encode/Decode) 2D/3D Graphics MIPI CSI camera port AC97 Audio In/Out Console UART Besides the Android support, Linux and WEC7 board support packages are also available for the i.MX6 Qseven SOMs from iWave systems. More details about the i.MX6 Qseven SOM & software features can be found in the i.MX6 Qseven product page. Device drivers will be supported for specific interface chipsets, which are used in iWave's Qseven Carrier board. More details about iWave i.MX6 Qseven development kit can be found in the following webpage: http://www.iwavesystems.com/product/development-platform/i-mx6-q7-development-kit-54.html

MYIR has released a cost-effective and power-efficient ARM Evaluation Kit (EVK) MYD-IMX28X for Freescale i.MX28 family of multimedia applications processors which has an ARM926EJ-S Core, with speed up to 454 MHz. The board can support running Linux operating systems, which allows developers to use it as an i.MX28 reference platform to quickly start their own design. The board takes full features of the i.MX28 ARM processor and has exposed a comprehensive set of peripherals and connectivity options to make the board suitable for smart gateways, human-machine interfaces (HMIs), handheld devices, scanners, portable medical, experimental education and more other industrial applications. The MYD-IMX28X Development Board is using the MYC-IMX28X CPU module as the heart of the system which is an ARM9-based system-on-module (SOM) integrated with the i.MX28 processor, 128MB DDR2 SDRAM, 256MB Nand Flash and Ethernet PHY. It is connected to the base board through two 1.27mm pitch 80-pin connectors. The base board has extended many peripherals and interfaces through headers and connectors, featuring 1 x RS232, 1, Debug, 2 x USB ports, up to 2 x Ethernet, 1 x CAN, 1 x RS485, TF, Audio, LCD, JTAG, etc. MYD-IMX28X Development Board MYC-IMX28X CPU Module MYIR offers the board with Freescale i.MX283 or i.MX287 ARM9 CPU by default; user can integrate a different MYC-IMX28X CPU module on the same base board, thus making two variants of i.MX28 evaluation boards. MYD-IMX283 Development Board – with MYC-IMX283 CPU Module for Freescale i.MX283 MYD-IMX287 Development Board – with MYC-IMX287 CPU Module for Freescale i.MX287 The MYD-IMX283 and MYD-IMX287 boards only have a few differences as described in below table: Model MYD-IMX283 MYD-IMX287 Processor i.MX283 i.MX287 CAN 0 2 Ethernet 1 2 The MYD-IMX28X board comes with Linux2.6.35 software packages, detailed documents, necessary cable accessories as well as optional 4.3- and 7-inch LCD (with touch screen) to provide a complete Freescale i.MX28 starter kit and enable a quickly start of evaluation of i.MX28 family applications processors.

Measuring only 70mm by 55mm, the MYS-6ULX designed by MYIR is a high-performance low-cost Single Board Computer specially designed for Industry 4.0 (Industrie 4.0) and Internet of Things (IoT) applications. The MYS-6ULX has DDR3, Nand Flash, USB, Ethernet, TF, LCD and more other core components and peripheral interfaces integrated on the tiny board. Furthermore, it has two 2.0mm pitch 2x20-pin headers on board to bring out as many as signals for user extensions. The MYS-6ULX single board computer has MYS-6ULX-IND and MYS-6ULX-IOT two different models, which are respectively for Industry 4.0 and IoT applications. The two boards share the same hardware circuit design and are fully compatible in software. The MYS-6ULX-IND is built around the i.MX 6UL processor family and can support -40 to +85 Celsius extended temperature operation, which makes the board more suitable for industrial control and communication applications. The MYS-6ULX-IOT is based on the i.MX 6ULL processor family and has additionally a USB based WiFi module with antenna on the board. MYIR has ported Linux 4.1.15 for the board with Debian distribution as well as Yocto project with ported QT. MYIR has also provided an interesting demo to enable customers to experience Amazon Alexa Voice Service. Additionally, MYIR has designed an expansion board MYB-6ULX to further enhance the performance of MYS-6ULX. It is connected to the MYS-6ULX board through its onboard two 2.0mm pitch 2 x 20-pin expansion headers and has extended one more Ethernet for MYS-6ULX and added CAN, RS485, Audio, RTC and Camera. MYIR also offers optional LCD modules and Camera module to add functionality to the boards, which would be a complete embedded system.                                                              MYS-6ULX-IND Single Board Computer                                                            MYS-6ULX-IOT Single Board Computer                    MYB-6ULX Expansion Board

CPU: ARM Cortex-A9,FreeScale i.MX6Q1Ghz/1.2Ghz 1024M Byte  DDR3 SDRAM,4G BYTE eMMC Flash 5 usart ， USB Host，USB OTG 124 bits TFT port ，dual LVDS output  and HDMI IIC*2，McSPI*3，CAN*2,SD card *3，6*6 keyboard 120 pin conn *2 FR4 PC size:84*55(mm)