i.MX Solutions Knowledge Base

Discussions

Freescale and Boundary Devices are excited to announce the availability of the i.MX6x Sabre Lite Board, a low-cost development platform featuring the powerful i.MX 6Quad Application Processor. $299 i.MX6 Development Board Highlights of the platform include: Quad-Core ARM® Cortex A9 processor at 1GHz 1GByte of 64-bit wide DDR3 @ 532MHz Three display ports (RGB, LVDS, and HDMI 1.4a) Two camera ports (1xParallel, 1x MIPI CSI-2) Multi-stream-capable HD video engine delivering H.264 1080p60 decode, 1080p30 encode and 3-D video playback in HD Triple Play Graphics system consisting of a Quad-shader 3D unit capable of 200MT/s, and a separate 2-D and separate OpenVG Vertex acceleration engine for superior 3D, 2D and user interface acceleration Serial ATA 2.5 (SATA) at 3Gbps Dual SD 3.0/SDXC card slots PCIe port (1 lane) Analog (headphone/mic) and Digital (HDMI) audio Compact size (3″x3″) 10/100/Gb IEEE1588 Ethernet 10-pin JTAG interface 3 High speed USB ports (2xHost, 1xOTG) 1xCAN2 port I2C GPIOs See Compatible Products for: 7″ Display SATA Cable 5MP Camera Android Button Board LVDS Cable for Freescale 10.1″ PCIE DB LEAD TIME IS CURRENTLY 2-3 WEEKS Cost will be $199 in Production (October 2012) Click here for more information.

New Taipei City, 27.Oktober 2015 – TechNexion announces PICO-i.MX6UL System-on-Module for Google Brillo OS Googles OS Brillo is a lightweight embedded OS, based on Android that is open, extensible, secure and applicable to a variety of devices. Brillo’ comes with ‘Weave’ Googles communication API, which easily allows ‘Brillo’ devices to communicate and exchange with each other or store data in the cloud. TechNexion provides with the PICO-IMX6UL System-on-Module (SoM) the fitting hardware for this new operating system. The PICO Module is equipped with a Freescale i.MX6 UltraLite Processor (Cortex-A7 Core) and is a very compact, ubiquitous computing, high performance SoM that are highly optimized for mobile Internet of Things applications. Connectivity is given by Gigabit Ethernet, WiFi (802.11ac) and Bluetooth 4.0. Memory ranges from 256MB over 512MB to 1GB DDR3 Available with on-board eMMC Memory (default 4GB, others available on request) or SD-Card Slot. Using a pin-compatible scale-able platform that not only utilizes the “Edison” connector connectivity for sensors and low-speed I/O, but also adds additional expansion possibilities for multimedia and connectivity. Additionally the “DWARF” platform eases proto-typing and accelerates time to market by offering a complete platform; introducing a large number of ready to use sensors like 3d-Accelerator, Gyroscope or Altitude-meter and available I/O’s to take advantage of todays’ technology and communication challenges, giving our customers’ cutting edge technology that can easily be expanded and implemented into Industry 4.0 applications. The schematics are freely available for the DWARF Carrier board. TechNexion’s Brillo Page is here: http://technexion.com/solutions/brillo The Freescale announcement is here: http://blogs.freescale.com/processors/2015/10/freescale-joins-google-in-enabling-brillo-access-to-the-developer-community/ And for more information you can find the Google announcement here: http://googledevelopers.blogspot.tw/2015/10/building-brillo-iant-devices-with-weave_27.html

Optimizing ARM Cortex-A9 support in Windows Embedded Compact A Discussion of random hangs and other issues using Windows Embedded Compact on Freescale i.MX6 Application Processor and how they were solved By Adeneo Embedded Engineering Team Rev 1.0, November 2014 Summary Over the last year Adeneo Embedded has been confronted with reports of random processor deadlocks and operating system crashes from customers using our Freescale i.MX6 Windows Embedded Compact Board Support Package. The random hangs and other issues surfaced while testing the devices comprehensively, i.e., regular CTK test passes did not bring out the failures to occur. A dedicated team of senior engineers in Adeneo worked with a number of our key customers to analyze and solve the issues across the board. With the latest version of the Adeneo i.MX6 Windows Embedded Compact (7 and 2013) BSPs we are confident this has been achieved. This white paper is about the investigation and shares some of our discoveries. All information in this document applies to Windows Embedded Compact 7 and 2013 as well as all variants of the i.MX6. Format of the investigation Based on the problem reports from the field it was complex to identify a single component in a system as the culprit, so we decided to use a formal and broad process to investigate the situation. A formal code review was done for the BSP code, Microsoft kernel code and customer application code; Lauterbach JTAG hardware debuggers were used to capture all available processor data at the time of crashes; Microsoft’s kernel team assisted with all questions around the Windows CE kernel; Customer’s engineering teams with their specific knowledge of their application developed test applications to replicate the problem more easily Freescale support engineers assisted with all questions around the silicon. Adeneo engineers redesigned the BSP from the ground and optimized it for i.MX6 and Cortex-A9 architecture In summary, the collaboration of multiple companies, and more important, a diverse group of dedicated individuals with unique value add provided the comprehensive technical coverage to develop the solution to this complex problem History of the i.MX6 BSP Starting point for the i.MX6 Windows Embedded Compact BSP were earlier BSPs for other application processors from Freescale like i.MX5x series and back to i.MX2x series. On the OS side the history goes back to Windows CE 5. The good thing with Freescale application processors is that they share peripheral IP blocks across a range of processors, so developers can share and reuse a lot of code. This was very helpful in the beginning to get a BSP working on the new i.MX6 SoC and get projects started. However, the i.MX6 with its multi-core Cortex-A9 architecture which made is challenging to reuse the code designed for single core Cortex A8 or ARM9 CPUs. In particular, cache management, multi-core support and memory configuration were the areas where existing Cortex-A8 and ARM9 code first was able to get enablement possible, but then failed in long-term stability tests. Cortex-A9 Architecture The Freescale i.MX6 Application Processor is an implementation of the ARM Cortex-A9 and ARMv7 Instruction Set architecture. This powerful architecture provides a number of features to improve the processing performance, but requires special attention when developing system software. The i.MX6 provides up to four cores in a symmetric multi-processing configuration under Windows Embedded Compact. Some of the stability affecting features addressed during the investigation are: Speculative load and execution Speculative table walks Branch prediction Out-of-order execution and instruction reordering Parallel internal busses Multiple internal buffers and caches Multi-core coherency L1/L2 cache operations Abort handling As part of our code review we identified shortcomings in existing code to correctly configure these features and take proper advantage of them. All code was verified with the ARM architecture documentation and updated to follow the latest recommendations by ARM. Freescale engineers helped to understand implementation details where ARM documentation is vague as it leaves some freedom to silicon vendors how to implement a feature. All errata documents from Freescale, ARM and other IP vendors were reviewed, and we made sure all applicable fixes or workarounds got implemented in BSP or kernel code. In discussion with customers we decided on a good working configuration for the i.MX6 processor that focuses on stability without compromising performance. In multi-core configurations we updated the code to operate all available cores in the same configuration at all times. A critical area was power management code to reapply the same settings when coming back from low power states. Memory Configuration Cortex-A9 provides a powerful memory management unit that allows it to implement a virtual memory system that operates the device in multiple modes, isolates application processes from each other and provides layers of protection and security. Looking at the memory space, we have several types of memory with this architecture. We focused on: Normal memory Device memory ARM architecture has a flat unified memory address space as compared to x86 architecture where we have a memory address space and an I/O address space. This means all our peripheral registers and other I/O addresses are mapped into the same address space together with RAM and ROM (memory-mapped I/O). By default, this is nothing new and not a bad design as it makes things easier for software and hardware developers. In previous versions of Windows CE and other OS all addresses where treated a normal memory and the only difference between RAM and I/O was to set the non-cache flag in the memory properties for I/O. For architectures up to Cortex-A8 this was enough to ensure a stable operation of a system. In particular with Cortex-A9 speculative engines the legacy approach causes problems. While some speculative features of the cores can be disabled, speculative table walks (which implicitly do speculative loads) can’t be disabled – for Normal Memory. So with Cortex-A9 it is necessary to use the extended access permission features of the architecture and configure all I/O memory as device memory. Device memory amongst others has the no-execute flag set in its properties (XN flag), and the processor doesn’t touch it during speculative operations. Under heavy load and stress this becomes an issue as the processor does more speculative operations per time and the chance to touch I/Os grows. It was one of the main reasons for crashes and deadlocks. For Windows CE, Microsoft introduced a new way for OEMs to report available memory to the kernel with Compact 7. However, since the issue described above is not an issue on x86 and older ARM architectures, the i.MX6 BSP inherited the old reporting style from its ancestors. With the legacy memory reporting the OEM fills a memory mapping table with the information about available memory and provides that to the CE kernel during startup. The kernel then creates the initial MMU page table with a cached and a non-cached entry per memory block from the OEM. For the MMU everything is normal memory. The new WEC7 model works with two tables, the old one for RAM and ROM, and a new one for I/Os (device table). All blocks in the device table are configured as device memory in the MMU and are protected then. This sounds straight forward, but the devil is in the details. The new model changes the way BSP code can use address translation during the early boot phase. Functionality in the startup code and the KITL component had to be updated in order to work with the new model and allow parameter transfer from boot loader code to OAL code. It is also not well documented and required kernel code reviews and discussions with Microsoft kernel engineers to fine tune this part of the code and optimize it for i.MX6. Another issue was that internal SRAM of the i.MX6, which in the first place appears as part of the processor’s I/O space, and so ended up in the device table. However, the internal RAM is used in low power modes to run power-management code while external RAM is in self-refresh, so it has to be mapped as normal memory without the XN flag set. After all, it wasn’t a trivial piece of work. Synchronization Barriers Due to the above listed enhancements in Cortex-A9 it is necessary to set synchronization points in the flow of operation at which the processor and all memory has a known state and is in sync. This is especially important when updating processor configuration or during context switches in the OS. Through code reviews of OAL and kernel code and in discussions with Microsoft we updated the BSP to meet all ARM requirements and fine tune the interfaces between kernel and OAL to provide optimal performance. Errata During the investigation we spent time on errata for the i.MX6 and its various IP blocks. BSP and kernel code where intensively reviewed for each erratum, if they are affected and a fix or workaround is necessary to be implemented. As part of this we also looked at the all software implemented BSP for i.MX6 (by Freescale) and its change log to double-check that we didn’t miss anything. Several critical errata were identified as missing in the code and implemented during the investigation. Three of the necessary code changes were in Microsoft kernel code and required a kernel update. Adeneo Embedded implemented these modifications in the kernel, tested the updated kernel in our test lab as well as with selected customers in the field, and then submitted the kernel change requests to Microsoft to formally release the update through the Windows Embedded Update mechanism. Cache Management The i.MX6 implements the Cortex-A9 architecture with an internal L1 data and instruction cache and an external L2 unified cache. Internal L1 means the L1 RAM array is located inside the ARM MPCore IP block, and each Cortex-A9 core in the MP cluster has its own L1 cache. External L2 means the L2 RAM array is located outside the ARM MPCore IP block but inside the SoC and connected to the internal AXI bus. Both RAM arrays are not accessible through processor load/store instructions. Cache memory allows the system to keep often used data in memory with faster access but this requires to synchronize cache memory and external SDRAM so that observers outside the processor-cache block can see data changes. When configured as SMP cluster some of the necessary L1 maintenance is done by the hardware cache controller. Since we may have up to 4 cores each with its own L1 cache, and a multi-tasking operating system which may assign the same execution thread to different cores due to context switches, it is necessary that all cores have the same synchronized view of the memory. This is done in hardware through the coherency unit in the MPCore as long as single addresses are affected. If the L1 needs maintenance as a whole software has to handle it. Software also has to handle all L2 cache maintenance operations. Cache maintenance gets invoked by the kernel normally, but there are a few situations where device drivers or even application software has to request cache maintenance. In any case, the OAL gets these requests and executes them. All cache related code in the OAL was updated and redesigned to meet the ARM architecture requirements and collaborate with the kernel in an optimized way. Shortcomings Cortex-A9 support in the cache maintenance code and maintenance requests from drivers were another major source of instability in the initial BSP. Some of the complications in this area are: Optimize L1 code to take advantage of the available hardware support Maintenance requests that include L1 and L2 require a specific procedure to make sure all levels of memory are in sync Maintenance requests can come from multiple threads and CPUs in parallel – L2 code has to be reentrant and multi-core safe DMA controllers work with physical addresses and do not know about caches; when DMA operations are used drivers have to make sure to request the necessary cache maintenance. Some instability with USB, SD and video operations were related to bugs in this area. Build and Testing As we learned at the beginning of this investigation that the CTK BSP testing failed to identify these issues we also reviewed our testing approach and implemented improved procedures. A new component in our testing is the stability lab, where we provide a dedicated set of hardware together with IT infrastructure to automate tasks and log results. With approval from our key customers we transferred customer test applications and applications that helped reproducing the issues into more generic test applications and added them to our portfolio. Another lesson learned is that knowledge of customer use cases is important. We restructured our testing to be closer to real world scenarios and integrate feedback from customers directly. A number of times during the investigation concerns were raised that the build process or the tools may be the root cause for some issues. Test teams reported different results based on where and how an OS image was built. We analyzed the tool installation and update process and the process to install OS bug fixes from Microsoft, but conclusion was that these observations were red herrings. But we used the knowledge gained from this part of the investigation to improve the build lab in Adeneo Embedded. We enhanced our infrastructure and upgraded tools so that it is easier for us to switch between versions and QFE levels of Windows Embedded Compact and our BSPs. Commitment This investigation was done over a period of about 8 months, and Adeneo Embedded put a committed effort into it to solve the problems. A core team of engineers worked fulltime on it while an extended group of engineers was available to support where needed (test, build, debugging, applications,..). The problems we had to solve here were not trivial; at times it was like a wild roller coaster ride. But as a result we have a Freescale i.MX6 Windows Embedded Compact board support package by Adeneo Embedded with significantly improved quality and optimized for this system-on-chip. This brings out the benefits to all customers running Windows Embedded Compact i.MX6 and future CPU architectures on similar ARM cores on WEC7 and WEC2013. For more information email the Adeneo Embedded Support Team at sales@adeneo-embedded.com or visit our website at http://www.adeneo-embedded.com/

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

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.

This webtalk session provides an overview of the new ConnectCore 6 multichip module. The industry’s first SMT multichip module built on the Freescale i.MX6 application processor family. Offering pre-certified and fully integrated wireless connectivity options such as 802.11a/b/g/n and Bluetooth 4.0 plus unique system capabilities such as an independent Kinetis K/L on-module subsystem, built for reliability and long-term availability. The module targets applications in healthcare/medical, transportation, industrial and other markets. Visit the link below to view the webtalk video now: http://www.embedded-know-how.com/boards-a-modules-main/article/45-boards-modules/1699

NXP i.MX7 processors, 1GHz Up to 2GB DDR3 and 32GB on-board eMMC LVDS, MIPI-DSI, Parallel RGB, up to 1920 x 1080 PCIe, 2x GbE, 5x USB2, 7x UART, 2x CAN, 124x GPIO Dual-band 802.11a/b/g/n WiFi and Bluetooth 4.1 BLE Yocto and Debian Linux, RTOS CL-SOM-iMX7 is a tiny System-on-Module (SoM) / Computer-on-Module (CoM) board designed to serve as a building block in embedded applications. CL-SOM-iMX7 is built around the Freescale 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 SLC NAND or eMMC storage. Featuring a wide range of embedded interfaces, CL-SOM-iMX7 is a versatile platform for industrial automation and control systems. Dual Gbit Ethernet, 2x2 MIMO dual-band 802.11a/b/g/n WiFi and Bluetooth 4.1 make CL-SOM-iMX7 an excellent solution for networking, communications and IoT applications. Low price makes CL-SOM-iMX7 an ideal selection for cost-sensitive systems, while its miniature size and low power consumption enable integration into portable and space-constrained designs. CL-SOM-iMX7 is provided with a full Board Support Package and ready-to-run images for the Linux operating system. The CL-SOM-iMX7 BSP includes Linux kernel 3.14, Yocto Project file-system and U-Boot boot-loader. In addition, CompuLab will support CL-SOM-iMX7 with mainline Linux and upstream Yocto Project. CL-SOM-iMX7 Detailed Spec CL-SOM-iMX7 Block Diagram CL-SOM-iMX7 Development Kit CL-SOM-iMX7 Online Pricing

The Nitrogen6X is a highly integrated development system based on the next generation ARM-Cortex A9 processor from Freescale, the i.MX6. Click here to visit Boundary Devices for full details See Compatible Products Tab for: 7″ Display SATA Cable 5MP Camera Android Button Board WiFi ADD-ON LVDS Cable for Freescale 10.1″ PCIE DB Available through Arrow Electronics. Cost will be $199 in Production for non-WiFi (October 2012)

This is a demo of the Nitrogen6X with BD_HDMI_MIPI daughter board. The Nitrogen6X is an i.MX6-based Single Board Computer (SBC) designed for both development and production use. The BD_HDMI_MIPI daughter board utilizes the Toshiba TC358743XBG HDMI to MIPI CSI part to convert the HDMI signals to MIPI. The BD_HDMI_MIPI can be used with our Nitrogen6X, BD-SL-i.MX6, Nitrogen6_MAX boards as well as the Nitrogen6X_Carrier. The daughter board can be used for evaluation as well as software development. Please contact Boundary Devices for custom version. This demo shows the Nitrogen6X running Yocto based on 3.10.17 kernel and displaying the output of our Nitrogen6X_SOM on a 10.1" LG BD101LIC1 display.

Here is a video that shows the NFC feature integrated into our Android Lollipop 5.0.0 code base. It is running on our Nitrogen6x platform along with the NXP PN7120 development kit. The video shows that a NFC tag, programmed with Boundary's URL, is automatically read and starts the Browser accordingly. In order to read/write data from a NFC data, Android provides a fully documented API. If you seek an existing application to write tags, here are a couple of options: NXP TagWriter app StickyNotes sample code For more information, please visit http://boundarydevices.com/

The DA9063 from Dialog Semiconductors is a powerful system PMIC for the next generation of single, dual and quad-core application processors based on the ARM Cortex™ A9 and A15 architecture. The PMIC follows a scalable approach of output currents and rails to supply the entire system and is capable of delivering a total of up to 12A from its six DC-DC converters. The DA9063 simultaneously powers the processor (the core at up to 5A), external memory, wireless communications (WLAN and Bluetooth), GPS and FM receivers, and data modems. The DC-DC converters can be paralleled to provide 3A and 5A rails. Description: DA9063 is a high current system PMIC suitable for Single, Dual and Quad-core processors used in smartphones, tablets and other handhelds applications that require up to a 5A core processor supply. There are multiple operating modes, five consuming <20μA including a 1.5μA RTC mode with alarm & wake up. A system monitor watchdog is enabled in Active mode. DA9063 contains 6x DC-DC Buck converters designed to use small external 1µH inductors capable of supplying in total up to 12A continuous output (0.3-3.3V). 11x SmartMirror™ programmable LDO regulators rated up to 300mA. All support remote capacitor placement and operate from low 1.5/1.8V input supply; this allows the linear regulators to be cascaded with a suitable buck supply to improve overall system efficiency. A number of LDOs can be configured as current limited bypass-switches to support external peripherals such as external accessory or memory cards. The Buck converters do not require external Schottky diodes, they dynamically optimise their efficiency depending on the load current using an Automatic Sleep Mode (ASM). They incorporate pin and s/w controlled Dynamic Voltage Control (DVC) to support processor load adaptive adjustment of the supply voltage. Processor core leakage reduction can be achieved using external FET switches driven by the rail switch controllers for ultra-fast power domain switching. The DA9063 provides a startup sequencing engine that offers autonomous hardware and software controlled system start-up. Customisable power modes can also be configured using “Power Commander,” Dialog’s powerful graphical user interface. The ON-key feature detects the button press time and offers configurable key-lock and application shut-down functions. Up to 16 free configurable GPIO pins are able to perform system functions including keypad supervision, application wake-up and timing controlled enable of external regulators/power switches or other ICs. A 10-bit ADC supports voltage and temperature supervision from general purpose inputs including automatic interrupt from comparators and resistor measurement. Three RGB-LED driver pins are provided with PWM control. LDO8 may be configured as a 6-bit PWM controlled vibration motor driver with automatic battery voltage correction. Features Input supply voltage range up to 5.5v 6 DC-DC Buck Converters with Dynamic Voltage control 2.5A Buck 2.5A Buck 2.5A Buck 1.5A Buck 1.5A Buck 1.5A Buck 3MHz Switching Frequency Enables use of 1.0mm high inductors Integrated Power Switches 11 LDO Regulators with programmable Output 3 low noise LDOs 4 with Dynamic Voltage Control 5 with current limited Switch option Fast controller for 2 Rail Switches Ultra low power 1.5µA Real-Time Clock with alarm, oscillator circuitry with crystal frequency adjustment and controlled signal provision Power Manager with programmable Start-up of internal and external regulators/rail switches and configurable low power modes Support of multiple master applications via two independent Control Interfaces System Monitor including Watchdog Timer Up to 16 free configurable GPIO Pins enable system control from DA9063 while the application is in standby RGB-LED driver (PWM) with autonomous flashing PWM vibration motor driver 10-Bit ADC with 9 Channels and configurable alarm thresholds Regulator Supervision with automatic under and over voltage protection Coin Cell/Super-Capacitor Backup Charger -40 to +85°C Temperature range 100VFBGA 8.0x8.0x1.0mm (0.8mm pitch) package Block Diagram DA9063: For more information: http://www.dialog-semiconductor.com/products/power-management/DA9063

NOVPEK TM i.MX6Q/D System Download the NOVPEK i.MXQ/D Brochure Includes NOVPEK TM i.MX6Q/D Module 201 easily accessible IOMUX pins Arranged in 32x2 100mil pin headers Advanced Power Management (PM) development support via Add-on Card, various PM options available Multiple voltage settings for each peripheral voltage rail Accurate power consumption analysis framework for all 35 voltage rails on the i.MX6Q/D On-board debug ports: JTAG and 16bit ETM Bootable with terminal support RS232 and TTL interfaces, only uses two i.MX6Q/D pins All i.MX6Q/D boot options Simplified firmware/software development through 10/100 Ethernet port SPI based, doesn’t consume the built-in FEC USB HOST port and USBOTG port that can be forced to HOST mode HDMI video out port SATA interface LVDS interface PCI Express Mini PCIe with SIM slot MIPI/SDI interface Highly integrated NovTech PM solution Multiple power-on events Reprogrammable for configurability For more information click here

LTC3676 datasheet Features Quad I 2 C Adjustable High Efficiency Step Down DC/DC Converters: 2.5A, 2.5A, 1.5A, 1.5A Three 300mA LDO Regulators (Two Adjustable) DDR Power Solution with V TT and VTTR Reference Pushbutton ON/OFF Control with System Reset Independent Enable Pin-Strap or I 2 C Sequencing Programmable Autonomous Power-Down Control Dynamic Voltage Scaling Power Good and Reset Functions Selectable 2.25MHz or 1.12MHz Switching Frequency Always Alive 25mA LDO Regulator 12μA Standby Current Low Profile 40-Lead 6mm × 6mm × 0.75mm QFN Package Linux Driver Instructions (Please note that this is a Beta Release Version) The driver is good reference code to illustrate how to communicate with LTC3676 via I2C. The .zip file also includes a test app and readme.txt with instructions. It has been tested with i.MX6Q NovPek board from NovTech. It is configured for the LTC3676-1 but also support LTC3676 by simply changing a flag and there are comments about the minor difference between the -1 and non-1 for the driver. Here is the description and instructions also contained in the included readme file: This package contains the linux driver for LTC3676 and LTC3676-1. It has been tested with i.MX6Q. It also includes a test app. It is configured for the LTC3676-1 but there are internal comments about the minor difference between the -1 and non-1 for the driver. Here are general instructions on how to include this new driver in the Linux build using ltib. You can also see that it is tested with linux-3.0.35 that Freescale has used for i.MX6. 1) cd ltib/rpm/BUILD/linux-3.0.35 (Where your Ltib folder is stored). 2) extract zip file: tar -zxpf LTC3676_Driver.tar.gz 3) Run LTIB configure: ./ltib -c 4) Select "Configure the kernel", exit, and yes to save. 5) When Kernel Menu appears, select "Device Drivers". 6) Select "Voltage and Current Regulator Support". 7) Select "Linear LTC3676 Regulator Driver" to compile into kernel. Don't build as a module. 😎 Exit and Save. 9) Ltib should build the kernel with the driver. Application Instructions: This builds in the ltc3676_1_test application to allow a user to check the regulators and dynamically change the voltage on the ARM core rail. The voltage movement is small to not push the i.MX6 outside normal operation. This test application does not have any overvoltage error checking for safety. It also does not change the processor frequency. It just tests the basic LTC3676 driver operation. 1) cd ltib (Where your Ltib folder is stored). 2) Run "./ltib -m prep -p imx-test" 3) Move the ltc3676_test folder extracted from this tar file: "mv rpm/BUILD/linux-3.0.35/ltc3676_test rpm/BUILD/imx-test-12.09.01/test/." 4) Run "./ltib -m scbuild -p imx-test" 5) Run "./ltib" 6) Burn SD Card, "./mk_mx6_sd -ukr /dev/sdb", /dev/sdb is the name of the SD card. 7) Safely Remove SD Card and install in NOVPEK board. 😎 Power and boot to Linux. 9) Run "cd /unit_test " 10) Run Application, ./ltc3676_1_test i.MX6 Board from NovTech (Click on this link) Schematics for LTC3676-1 Linear Technology Power Plug in Board available. Contact your local Linear Technology sales office Gerard Velcelean (gvelcelean@linear.com) or Steve Knoth (sknoth@linear.com) if you have any questions.

REX - Freescale iMX6 Opensource Project Designed by FEDEVEL Academy Based on Freescale i.MX6 CPU. This is an open source project. All documents are free for download, including Schematic and PCB files. The iMX6 Rex Module is also used for teaching about Schematic Design and Advanced PCB Layout at FEDEVEL Academy. Module Specification Freescale iMX6 processor, up to 1.2GHz / 4 cores Soldered down DDR3-1066 (533MHz), up to 4GB 10/100/1000 Mbps Ethernet 1x HDMI (up to QXGA 2048×1536) 1x LVDS (up to WUXGA 1920×1200) 1x PCIE 1x SATA On board SPI Flash up to 32Mb 1x SD, 1x MMC 2x USB 3x UART, 3x I2C, 1x SPI Digital audio JTAG User LED, power LED 2x high speed board to board connectors (only one required) Size: 70 x 40 mm (smaller than a credit card) Input power: 7 to 24 V (DC) Releated posts iMX6 Rex EMC Testing – Pass iMX6 Rex infrared images User friendly GUI + Mouse + Keyboard working ok How long it took to design the iMX6 Rex module prototype? iMX6 Module Total Cost Prototype Developement The iMX6 Rex module design licensing Video from Assembling iMX6 Rex Boards Bringing up i.MX6 Rex Module to Life – from unpacking to booting iMX6 Rex Layout Video

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

Hi all, Below is our press release for our i.MX6 solutions, i.e., kits and boards. emtrion GmbH, a company specialised in Embedded Systems design, hardware and software, Freescale Proven Partner, announces the availability of a new industrial processor module based on the multicore Cortex-A9 i.MX6 SoC family from Texas Instruments. This new module, called DIMM-MX6, extends the emtrion DIMM family and offers a full electrical and mechanical compatibility with the other modules of the emtrion DIMM series. emtrion guarantees the availability of its new module for at least 10 years. The DIMM-MX6 module from emtrion brings high computing capabilities with up to 10.000 DMIPS, multiple NEON SIMD and VPFU co-processors at a low power level, without requiring any active cooling system. The DIMM-MX6 module is available in several versions, with either i.MX6 Solo (1 core), Dual (2 cors) or Quad (4 cores) and on-board memories ranging from 512MB up to 8GB for the Flash (SLC NAND) and from 512MB up to 2GB RAM (DDR3). The new module is also qualified for an extended temperature range of -40°C to +85°C. In addition to boards and kits, emtrion offers support for a broad range of operating systems, board support packages (BSP) as well as engineering services. The DIMM-MX6 is available now with a BSP for Linux, that will be followed by additional BSP for Windows Embedded Compact 7 (WEC7), for QNX 6.5 and for Android 4.0. The BSP are available together with a developer kit. Each developer kit includes a DIMM-MX6 industrial module, a base board, a display and a development environment. All parts are mounted together and programmed by emtrion. The kits are shipped ready to use.

This document will explain Cairo setup to draw something on screen with hardware accelerates using OpenGL ES 2.0 or OpenVG. Introduction: As you know you can use those libraries that I mentioned (OpenGL ES and OpenVG) to draw on frame buffer with hardware accelerate on imx6q but using those libraries are a little bit hard to deal what I mean is that using OpenGL or OpenVG is a kind of tough job but why? Let me bring an example here to clarify it, Imagine you want to draw an attitude aircraft symbol, this symbol needs some of elements to be drawn to look like a complete attitude symbol it includes: 1-Circle 2-line 3-Text 4-Triangle 5-some custom shapes for instance two L like lines that draw horizontally If you have an experience with OpenGL specially OpenGL ES you’ll realize that drawing circle, line, triangle and so forth doesn’t a really tough job, of course drawing these primitive in OpenGL needs more lines of code in contrast with Cairo API that you can draw them with just three lines of code but the most hard job is drawing TEXT in OpenGL when you want to draw a simple text you have to deal with extra libraries like freetype,… to fetch the glyph features and then you can using atlas approach to draw text in a bitmap texture then when you need a character in your app you can access to the character’s position in previous stored glyph in the texture, fetch and use, also you need to work with two specific OpenGL ES shaders in this case. So I think it’s ok to use OpenGL or OpenVG to draw shapes if you are really skilled with those or if you looking for trouble! 😄 personally I prefer to use a high level API and then focus on other aspect of my application. Compiling Cairo: This document doesn’t intend to configure or compile Cairo, I’m sure that you can easily configure and compile it with OpenGL ES backend with YOCTO, Buildroot or any other embedded Linux distribution builders (YOCTO and Buildroot aren’t an embedded Linux distributions they can make custom one for you) even you can compile it manually. To configure: ./configure --prefix=/home/super/Desktop/ROOTFS/MY_ROOTFS/usr --host=${CROSS_COMPILE} CFLAGS="-I/home/super/Desktop/ROOTFS/MY_ROOTFS/usr/include/ -DLINUX -DEGL_API_FB" LIBS="-L/home/super/Desktop/ROOTFS/MY_ROOTFS/usr/lib/ -lz" --enable-xlib=no --enable-egl --enable-glesv2 To compile: make By the way you can find your suitable configuration for your own board; Cairo has a lot of options. How to make surface for Cairo: If you have an experience drawing shapes with Cairo you know that you need a surface from cairo_t* type to drawing function API can work on and shapes appear on the screen. To create a Cairo surface that uses OpenGL ES you have to configure EGL (EGL is an interface between Khronos rendering APIs (such as OpenGL, OpenGL ES or OpenVG) and the underlying native platform windowing system)[1] correctly and then make a Cairo surface from it. EGLint config_attributes[] = { EGL_RENDERABLE_TYPE, EGL_OPENGL_ES2_BIT, EGL_RED_SIZE, 8, EGL_GREEN_SIZE, 8, EGL_BLUE_SIZE, 8, EGL_ALPHA_SIZE,EGL_DONT_CARE, EGL_SURFACE_TYPE,EGL_WINDOW_BIT, EGL_DEPTH_SIZE, 16, EGL_SAMPLES, 4, EGL_NONE }; When you want to change OpenGL ES v 2.0 with OpenVG it’s enough that change the parameter of EGL_RENDERABLE_TYPE (that is EGL_OPENGL_ES2_BIT) to EGL_OPENVG_BIT. The below code will appear Figure 1 on screen: Figure 1:Simple drawing by Cairo on IMX6Q //~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ //======================================================================== // Name : testCairo.cpp // Author : Ali Sarlak // Version : 1.0 // Copyright : GPL // Description : EGL+Cairo GLIB //======================================================================== #include <iostream> #include <stdio.h> #include <EGL/egl.h> #include <EGL/eglext.h> #include <EGL/eglplatform.h> #include <cairo/cairo-gl.h> #include <EGL/eglvivante.h> #include <stdlib.h> #define DISPLAY_WIDTH 640 #define DISPLAY_HEIGHT 480 using namespace std; int main() { printf("START\n"); printf("~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n"); EGLContext eglContext; EGLSurface eglSurface; EGLBoolean resultB; /* Get a display handle and initalize EGL */ EGLint major, minor; EGLDisplay eglDisplay = eglGetDisplay(EGL_DEFAULT_DISPLAY); resultB = eglInitialize(eglDisplay, &major, &minor); EGLint config_attributes[] = { EGL_RENDERABLE_TYPE, EGL_OPENGL_ES2_BIT, EGL_RED_SIZE, 8, EGL_GREEN_SIZE, 8, EGL_BLUE_SIZE, 8, EGL_ALPHA_SIZE,EGL_DONT_CARE, EGL_SURFACE_TYPE,EGL_WINDOW_BIT, EGL_DEPTH_SIZE, 16, EGL_SAMPLES, 4, EGL_NONE }; EGLint numberConfigs = 0; EGLConfig* matchingConfigs=NULL; if (EGL_FALSE == eglChooseConfig(eglDisplay, config_attributes, NULL, 0, &numberConfigs)) { printf("eglChooseConfig EROR\n"); } if (numberConfigs == 0) { printf("eglChooseConfig EROR\n"); } printf("number of configs = %d\n", numberConfigs); /* Allocate some space to store list of matching configs... */ matchingConfigs = (EGLConfig*) malloc(numberConfigs * sizeof(EGLConfig)); if (EGL_FALSE == eglChooseConfig(eglDisplay, config_attributes, matchingConfigs, numberConfigs, &numberConfigs)) { printf("eglChooseConfig EROR\n"); if(matchingConfigs!=NULL) { free(matchingConfigs); matchingConfigs=NULL; } return -1; } printf("~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n"); EGLint display_attributes[] = { EGL_WIDTH, DISPLAY_WIDTH, EGL_HEIGHT, DISPLAY_HEIGHT, EGL_NONE }; /*Window attributes*/ EGLint window_attribList[] = { EGL_NONE }; EGLNativeDisplayType eglNativeDisplayType = fbGetDisplay(0); EGLNativeWindowType eglNativeWindow = fbCreateWindow(eglNativeDisplayType, 0, 0, DISPLAY_WIDTH, DISPLAY_HEIGHT); eglSurface = eglCreateWindowSurface(eglDisplay,matchingConfigs[0],eglNativeWindow,window_attribList); if (eglSurface == EGL_NO_SURFACE) { printf("eglSurface = %x\n", eglGetError()); } const EGLint attribListCtx[] = { // EGL_KHR_create_context is required EGL_CONTEXT_CLIENT_VERSION, 2, EGL_NONE }; eglContext = eglCreateContext(eglDisplay, matchingConfigs[0], EGL_NO_CONTEXT, attribListCtx); //~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ if (eglContext == EGL_NO_CONTEXT) { printf("eglContext = %x\n", eglGetError()); return -1; } cairo_device_t* cdt = cairo_egl_device_create(eglDisplay, eglContext); eglMakeCurrent(eglDisplay, eglSurface, eglSurface, eglContext); cairo_surface_t *surface = cairo_gl_surface_create_for_egl(cdt, eglSurface, DISPLAY_WIDTH,DISPLAY_HEIGHT); cairo_t *cr = nullptr; cr = cairo_create(surface); if(!cr) { printf("Wrong cairo_t!\n"); return -1; } //********************************************************************************************* for (int index = 0; index < 1; ++index) { cairo_set_source_rgb (cr, 0, 0, 0); cairo_move_to (cr, 0, 0); cairo_line_to (cr, 200, 200); cairo_move_to (cr, 200, 0); cairo_line_to (cr, 0, 200); cairo_set_line_width (cr, 1); cairo_stroke (cr); cairo_rectangle (cr, 0, 0, 100,100); cairo_set_source_rgba (cr, 1, 0, 0, 0.8); cairo_fill (cr); cairo_rectangle (cr, 0, 100, 100, 100); cairo_set_source_rgba (cr, 0, 1, 0, 0.60); cairo_fill (cr); cairo_rectangle (cr, 100, 0, 100, 100); cairo_set_source_rgba (cr, 0, 0, 1, 0.40); cairo_fill (cr); cairo_rectangle (cr, 100, 100, 100, 100); cairo_set_source_rgba (cr, 1, 1, 0, 0.20); cairo_fill (cr); cairo_surface_flush(surface); eglSwapBuffers(eglDisplay,eglSurface); } //to check that cairo can make the photo from the surface, png file created cairo_status_t s = cairo_surface_write_to_png(surface, "surface.png"); //it is a photo that made by cairo [OK] cairo_destroy(cr); if (CAIRO_STATUS_SUCCESS == s) { printf("Status = OK \n"); } else { printf("Status = ERROR <ERROR_CODE->%d>\n", s); } if(matchingConfigs!=NULL) { free(matchingConfigs); matchingConfigs=NULL; } cairo_surface_destroy(surface); printf("END!\n"); return 0; } How To Be Sure That My Application Using GPU: If you have a look at https://community.nxp.com/thread/324670 you can profile a graphical application and investigate if it uses GPU or not, also you can measure the performance and analyze the application by vAnalyzer. According to the link I’ve mentioned that’s enough to set galcore.gpuProfiler=1 in uboot and then check the /sys/module/galcore/parameters/gpuProfiler file (read the file by cat, vi, nano, etc.) if the output is 1 all things is done in a right way the final step is that exporting some environment variables : export VIV_PROFILE=1 export VP_OUTPUT=sample.vpd export VP_FRAME_NUM=1000 export VP_SYNC_MODE=1 VIV_PROFILE[0,1,2,3], VP_OUTPUT[any string], VP_FRAME_NUM[1,N], VP_SYNC_MODE[0,1] Note: VIV_PROFILE[0] Disable vProfiler (default), VIV_PROFILE [1] Enable vProfiler, VIV_PROFILE [2] Control via application call, VIV_PROFILE [3]Allows control over which frames to profile with vProfiler by VP_FRAME_START and VP_FRAME_END. If application uses GPU smaple.vpd file will create if not there isn't any vpd file. [1] - https://www.khronos.org/egl

The Wandboard is a ultra low power complete computer with high performance multimedia capabilities based around the new upcoming Freescale i.MX6 Cortex-A9 processor and comes with a dazzling 1Ghz processor HDMI display interface and gigabit ethernet. The dualcore version of the Wandboard (The Wandboard DUAL) not only features 1GB of memory but also has onboard Wi-Fi and Bluetooth. Wandboard Solo Wandboard Dual Processor Freescale i.MX6 Solo Freescale i.MX6 Duallite Cores Cortex-A9 Single core Cortex-A9 Dual core Memory 512 MB DDR3 1 GB DDR3 Audio • • Optical S/PDIF • • HDMI • • Camera interface • • micro SD cardslot 2 2 Serial port • • Expansion Header • • USB • • USB OTG • • SATA connector Not populated Not populated Gigabit LAN • • WIFI (802.11n) • Bluetooth • 69 USD 89 USD www.wandboard.org Contact person : wandboard@gmail.com

iWave, a reliable embedded solutions provider has now optimized the booting time of its Windows Embedded Compact 7 (WEC7) BSP for Freescale’s SABRE SDP/B platform. Now the WEC7 OS is booting in a short period of time ~3 seconds for a small footprint OS image with display and touch drivers support, and boot time of ~8 to ~10 seconds for an OS image with basic drivers and OS components support. Why boot time optimization? WinCE7 is a real time OS which will be used in performance-critical applications such as automotive and healthcare units. In most of the cases, booting time will play important role, e.g. if the device is used in rear-view camera system in automotive field, the user needs the device to start working as soon as the reverse-gear is applied. This requirement needs the device to boot and start the camera application within few seconds. This demands a very short OS boot time. Some of the techniques which can be applied for efficient boot time optimization are discussed in this article. Boot phases in WEC7: Boot-loader (eboot) Copying of OS image from booting device (e.g. Micro-SD) to RAM OAL Layer Driver initializations and file system mounting Guidelines for reducing the boot time in different booting phases of WEC7: Boot-loader (eboot): Remove the code that initializes a hardware which is not required in boot-loader. E.g. If booting device is micro-SD, the initialization of NAND is not necessary. So, this redundant code needs to be removed. The eboot menu in eboot is important for debugging of WEC7 OS. But it is not needed in an end product. So, the delay for this eboot menu can be completely removed to reduce 3 seconds of time. In few platforms such as Freescale’s SABRE platform, a default splash screen is used, which updates continuously. This can be removed, and a static splash screen can be displayed, which can save a few milliseconds of time. Remove unnecessary serial debug prints. Copying of OS image from booting device (e.g. Micro-SD) to RAM: This time increases as the size of WEC7 OS image increases. So, select the OS components carefully and remove redundant components from OS image so that the OS image can be copied to RAM quickly. Also remove unnecessary registry keys, dlls and libraries to reduce the OS size. Optimize binary image builder (.bib) file to reduce the run-time image file. Implement Multi-BinFS OS binaries to reduce the OS copying size. As the functionalities/driver supports goes on increasing, WEC7 image size increases. So, the time required to copy the image increases, and RAM size needed to store the OS image increases. The Binary ROM Image File System (BinFS) can fix the two issues. In a BinFS file system, the WEC7 OS binary is divided into multi-binary Image files, and only the one binary (less than 5MBs) is copied into the RAM by the boot-loader. The components in the other binary files are copied into the RAM only when they are required to run. Links that can be referred to implement multi-BinFS in WinCE: MSDN documentation: http://msdn.microsoft.com/en-us/library/aa516960.aspx; An implementation guide by Freescale: http://cache.freescale.com/files/dsp/doc/app_note/AN4137.pdf You can also include compressing-decompressing mechanisms in boot-loader to achieve even shorter copying time. OAL layer: Remove the code that does unnecessary hardware implementations. Skip the initializations that already done in eboot. Remove any wait/loop/delay if exists. Remove unnecessary serial debug prints. Driver initializations and file system mounting: Analyse and remove all the redundant drivers, check for any loop, wait or delay sequences in driver initialization code. Load any applicable drivers (e.g. USB, sensors) after the OS boot (i.e. after user sees a desktop/application). In WEC7 OS, a driver can be either loaded during booting using device manager/GWES, or can be loaded dynamically whenever necessary. This can be achieved easily by changing the registry key configurations to remove the driver from built-in drivers, a small application to load the driver after OS boot-up, and registry settings to launch this application automatically once the OS is booted. To decide the load order, it is important to check the dependencies of/on a driver. Use appropriate splash screen/progress bar while user waits for OS booting. Remove unnecessary serial debug prints. By effectively following the techniques mentioned, WEC7 based platforms can achieve reduced boot time for quick application access. iWave has optimized the WEC7 booting time on Freescale’s SABRE SDP platform. The booting time is as low as ~3 seconds for a WEC7 OS with standard shell, LCD display, DDraw, I2C and touch driver support, and ~8 to 10 seconds for WEC7 OS with following components: Standard shell Display DDRAW Capacitive touch screen MicroSD USB host – Mass storage and HID Ethernet GPU (OpenVG/GL) Multimedia codecs DirectShow Audio Video Playback Ambient Light Sensor Accelerometer SMP PWM Backlight I2C Debugging using KITL For further information or inquiries please write to mktg@iwavesystems.com or visit www.iwavesystems.com

i.MX Solutions Knowledge Base

i.MX Solutions Knowledge Base

Discussions

imx_builder --- standalone build without Yocto

SABRE Lite by Boundary Devices

PICO-i.MX6UL and DWARF - ready for Brillo - TechNexion

Optimizing ARM Cortex-A9 Support in Windows Embedded Compact by Adeneo Embedded

Boundary Devices - FreeRTOS BSP v1.0.1 for Nitrogen7 & Nit6_SoloX

Boundary Devices - Using the Cortex-M4 on the Nit6_SoloX

Webtalk: Digi announces Freescale i.MX6 surface mount multi-chip module with built-in wireless connectivity and Kinetis microcontroller assist (ConnectCore 6)

CL-SOM-iMX7 - Freescale i.MX 7 System-on-Module | Computer-on-Module by CompuLab Ltd.

Nitrogen6X by Boundary Devices

HDMI Input on i.MX6 SBC

Boundary Devices - Android Lollipop NFC demo

System PMIC for i.MX6 (including Quad)

NovPek i.MX6Q/D by NovTech

LTC3676 PMIC, Linux Beta Drivers & Development Board Now Available for i.MX6

REX - Freescale iMX6 Opensource Project

IOT-GATE-iMX7 - NXP i.MX7 Internet of Things Gateway

Emtrion's i.MX6 DIMM Modules and Kits

Using Cairo graphic library on IMX6Q

The Wandboard - ultra low power high performance low cost development board with Freescale i.MX6 Cortex-A9 processor

Boot Time Optimization in Windows Embedded Compact 7 OS for Freescale i.MX6 Sabre SDP