i.MX Solutions Knowledge Base

cancel
Showing results for 
Search instead for 
Did you mean: 

i.MX Solutions Knowledge Base

Labels
  • General 295

Discussions

Sort by:
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.
View full article
Community has been working hard on FSL Community BSP Project for about 3 years now! We have achieved some great things and milestones together such as the number of supported boards that is about 40 right now! (with different SoC families and vendors.) The FSL Community BSP is a community driven project to provide and maintain a Board Support Package (BSP) meta layer and documentation to be used with the Yocto Project. The BSP provides a solid base for product development and easy adoption of current and new platforms. The landing page for FSL Community BSP Project is http://freescale.github.io. The current BSP offers support for several boards, including most of Freescale reference designs, provides an updated Release Notes document which contains the reference for all supported boards, documentation, contributing guidelines and more. Please visit our page at http://freescale.github.io and learn how to download the source code, how to contribute and how to subscribe to our mailing list.  Contact meta-freescale@yoctoproject.org if any questions.
View full article
PMIC PF3000/3001 + i.MX 6UL Resources: ========================================================================================================================= Upload the latest version D as enclosed, SCH-29105 KIT6UL_3000EVM Version D and SCH-29105 KIT6UL_3000EVM Version D. The attachment SCH-29105 KIT6UL-3000EVM Version C.zip includes i.MX 6UL 14x14 + PMIC PF3000(KIT6UL-3000EVM, SCH-29105 Rev.C) related files: No. Files in SCH-29105 KIT6UL-3000EVM Version C.zip 1 SPF-29105_C.pdf is the corresponding schematic PDF version. 2 SCH-29105_C.zip is the schematic. 3 LAY-29105_C.zip is the PCB layout. 4 750-29105_C BOM.xls is the BOM.   Its i.MX 6UL 14x14 + PMIC PF3000 BSP: Apply PF3000 driver patch in imx_3.14.52_1.1.0_ga http://git.frees cale.com/git/cgit.cgi/imx/linux-2.6-imx.git/commit/?h=imx_3.14.52_1.1.0_ga&id=e5a7a72cd51a585b8f1a1e299bf88fff44b94440 Apply 0001-add-pf3000-on-imx6ul-evk-board.patch, see the attachment. Apply 0003-correct-arm-soc-regulator-for-pf300.patch, see the attachment. Apply 0001-u-boot-add-pf3000-support-on-imx6ul-14x14-evk-board.patch, see the attachment.        2.  Update customer board dts as the above 0001-add-pf3000-on-imx6ul-evk-board.patch.   ========================================================================================================================= The attachment SCH-29090 KIT6UL-3001EVM Version C.zip includes i.MX 6UL 14x14 + PMIC PF3001(KIT6UL-3001EVM, SCH-29090 Rev.C) related files: No. Files in SCH-29090 KIT6UL-3001EVM Version C.zip 1 SPF-29090_C.pdf is the corresponding schematic PDF version. 2 SCH-29090_C.zip is the schematic. 3 LAY-29090_C.zip is the PCB layout. 4 750-29090_C BOM.xls is the BOM.   Its i.MX 6UL 14x14 + PMIC PF3001 BSP: Apply PF3001 driver patch in imx_3.14.52_1.1.0_ga http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/commit/drivers/regulator/pfuze100-regulator.c?h=imx_3.14.52_1.1.0_ga&i d=19708058f049be9a5dcc81943d1b9a14080367e8 Update PF3001 dts board file as customer board dts.   Thanks, PMIC team: Sean Liu
View full article
Abstract Security is an inevitable word which we heard in our day to day life. Technologies without security are technologies without “trust” for many of us. We all know how security plays an important role in our life starting from working place to social chat. Even Embedded Systems should implement security to prevent un-authorized access to the sensitive data. How we can assure i.MX6 platforms can only boot with authorized images? Let’s have a look into the cool stuff named High Assurance Booting (HAB) which makes the booting images secure and simple. Introduction Digital Security becomes unavoidable part of our life since from its birth. This case is not different for even any embedded systems, especially if it dealing with sensitive data. Many embedded devices which are using for bank dealings, defense, medical, industrial and automotive filed strictly implementing security. Almost all embedded systems are working based on the certain instructions given through flashed images. Imagine if a hacker can flash his own instructions to an embedded device, then he can take full control on what need to be done on that device. If the device is using for bank purpose, then hacker will get all details including the passwords! This scenario becomes even worse if the device is using for defense or medical field. How we can prevent this case? Well the answer is not quite simple! Embedded system OS images can flash from different mediums such as MMC, SD card, SATA, Ethernet etc. Implementing security checking on the medium will be difficult since mediums such as SD card can be easily replace one to another. Moreover, one can alter the OS images after flashed into these mediums. So, implementing a security check only before flashing the image will not be sufficient to address this issue. Then how we can implement a security check for making sure our OS images are well secure? The answer is HAB (High Assurance Boot). Freescale provided HABv4 (latest HAB version 4) as an optional feature in i.MX6Q processor. HAB is part of Freescale security block and can work with other security features such as CAAM and TrustZone. The advantage of using HAB includes but not limits to the following: HABv4 implements boot ROM level security which cannot alter once it fused. Efficient. Security checks before images are taking control of the system. Allow multiple root keys. Make use of digital signature – most efficient way to secure the OS images. Appending security directly to the OS images without affecting the OS image functionalities. Processor level checking with OS images validation gives complete assurance of the secure booting. How HAB works? HAB based on the principle of digital signature. Digital signature makes the content into secure through signing the content context. This signing process shall incorporate more than one security algorithm to strengthen the final outcome. HAB digital signature is combination of open-ssl certification, MD5 hashing and RSA-AES-DES public and private key checks. HAB ensure security by making both boot loader (u-boot) as well as OS image (uImage) into signed images. These signed images contain normal image content and security instructions. These images also contain the public key and private key too. During HAB process, the public key hash code which derived from the combination shall fuse into the boot ROM code of i.MX6 processor. This fusing make the platform more secure and cannot be altered later. During the booting time, first the initial parameters of boot process shall take into boot ROM code from the flash medium (say SD card). Then the HAB instructions will examine the hash values which present inside the boot ROM and signed images. When these two hash values matches, then HAB process allow the platform to boot the images. Else the system shall stop all the process and wait for the authorized images. In this way, the system shall protect from un-authorized access, even somebody changes the signed images at later stage (this eventually change the hash value of the image and hence failed during the run-time check). iWave has successfully implemented the HAB in our i.MX6Q iW-RainboW-G15D-Q7 Linux platform and validated the HAB to know how it can secure the platforms. However HAB is not part of the standard BSP delivered as a part of development platform purchase or module purchase. This is available only on special request. Conclusion HAB is one of the best solutions to prevent un-authorized access to the OS images. Embedded systems which are dealing with sensitive data (banking, defense etc.) should in-corporate HAB to prevent from taking control of the whole system by external sources. Though HAB is optional feature in i.MX6 platforms, it would be recommended to implementing it for making the booting process more secure. Reference: AN4581_HAB_Application_Note.pdf - Secure Boot on i.MX50, i.MX53, and i.MX 6 Series using HABv4 Application Note i.MX_6_Linux_High_Assurance_Boot_(HAB)_User's_Guide.pdf - i.MX 6 Linux High Assurance Boot (HAB) User's Guide
View full article
RIoTboard is an open source, single board, platform based on the i.MX 6Solo processor using ARM® Cortex®-A9 architecture, designed to help speed development with the designer and hobbyist in mind.     • Faster time-to-market • Low cost • Supports Linux and Android Jelly Bean • Open platform reference design   • Open source • Developer focused community RIoTboard.org • Reference design available as creative commons (Click to Enlarge) • NXP-enabled design i.MX 6Solo processor based on ARM® Cortex®-A9 Core® architecture, operating at speeds up to 1 GHz. Integrated debug circuit using the Kinetis K20 MCU PMIC (Power Management Integrated Chip) (MMPF0100)   Begin your revolution at R IoT board.org  
View full article
Mar 13, 2020: imx_builder_03122020.tgz  --- change the i.MX8MN  configuration.  Dec 11, 2019: imx_builder_12112019.tgz --- add support  L4.19.35_1.1.0 August 28, 2019:  imx_builder_08282019.tgz   --- add i.MX8MM July 03, 2019:  imx_builder_07032019.tgz --- add i.MX8QM: build_i.MX8  Feb 26 , 2020: imx_builder_02262020 --- add i.MX8MN, add spl m4 for build_i.MX8, build_i.MX8X with L4.14.98_2.0.0_ga, L4.14.98_2.2.0, L4.19.35_1.1.0 imx_builder_02262020: imx_builder |-- atf -> bsp/imx-atf |-- bsp -> REL/rel_imx_4.19.35_1.1.0 |-- build -> build_i.MX8X/L4.19.35_1.1.0 |-- build_i.MX6 |   |-- L3.0.x |   |-- L3.1x.xx |   |-- L4.14.xx |   |-- L4.19.xx |   `-- L4.1.xx |-- build_i.MX8 |   |-- before_L4.14.98_2.0.0_ga |   |-- L4.14.98_2.0.0_ga |   |-- L4.14.98_2.2.0 |   `-- L4.19.35_1.1.0 |-- build_i.MX8M |   |-- before.L4.19.35 |   `-- L4.19.35 |-- build_i.MX8MM |   |-- before.L4.19.35 |   `-- L4.19.35 |-- build_i.MX8MN |   `-- L4.19.35 |-- build_i.MX8X |   |-- before_L4.14.98_2.0.0_ga |   |-- L4.14.98_2.0.0_ga |   |-- L4.14.98_2.2.0 |   `-- L4.19.35_1.1.0 |-- dts -> linux/arch/arm/boot/dts |-- dts64 -> linux/arch/arm64/boot/dts/freescale |-- dts_uboot -> u-boot/arch/arm/dts |-- imx-mkimage -> bsp/imx-mkimage |-- linux -> bsp/linux-imx | -- m4_img |   |-- m4_1_image.bin -> rpmsg_lite_str_echo_rtos_imxcm4.bin |   |-- m4_image.bin -> power_mode_switch.bin |   `-- readme.txt |-- Makefile -> build/Makefile |-- Others |   |-- clk_module |   |-- cryptodev-linux-1.8 |   |-- helloworld_module |   |-- key_blob_module |   `-- spi |-- out |-- README -> build/README |-- REL |-- scfw -> bsp/scfw |-- SETTINGS.MK -> build/SETTINGS.MK |-- toolchains |   `-- scfw |-- u-boot -> bsp/uboot-imx `-- VERSION.MK imx_builder is a set of Makefile for build u-boot, Linux kernel, atf, scfw, imx-mkimage.  You can call it standalone build. here is the step to try it.  You can use  -n for make to get the detail build steps. ex:  make atf -n         make linux.Image -n L4.14.78_ga as example: 1. Untar  imx_builder_02282019.tgz 2. Read the  Standalone_Build_Preparation.pdf inside to prepare the bsp. 3. Prepare the toolchains(populate_sdk from yocto, get from linaro, get from buildroot, etc.) 4. Prepare scfw toolchains following the SCFW Porting Kit.  5. Follow the  Standalone_Build_Preparation.pdf to check if the Build Structure is correct. Build Structure L4.14.78_1.0.0_ga as example. Prepare rel_imx_4.14.78_1.0.0_ga in REL Make symbol link to REL/rel_imx_4.14.78_1.0.0_ga Make symbol link to build_i.MX8X   imx_builder/ |-- atf -> bsp/imx-atf |-- bsp -> REL/rel_imx_4.14.78_1.0.0_ga |-- build -> build_i.MX8X |-- build_i.MX6 |-- build_i.MX8M |-- build_i.MX8X |   |-- Makefile -> Makefile.4.14.78_ga |   |-- Makefile.4.14.78_ga |   |-- README |   |-- SETTINGS_4.14.78_1.0.0_ga.MK |   |-- SETTINGS.MK -> SETTINGS_4.14.78_1.0.0_ga.MK |   `-- VERSION.MK |-- dts -> linux/arch/arm/boot/dts |-- imx-mkimage -> bsp/imx-mkimage |-- linux -> bsp/linux-imx |-- Makefile -> build/Makefile |-- Others |-- out |-- README -> build/README |-- REL |   `-- rel_imx_4.14.78_1.0.0_ga |        |-- firmware-imx-8.0.bin |       |-- imx-atf |       |-- imx-mkimage |        |-- imx-sc-firmware-1.1.bin(optional) |        |-- imx-scfw-porting-kit-1.1.tar.gz |        |-- linux-imx |        `-- uboot-imx |-- scfw -> bsp/scfw |-- SETTINGS.MK -> build/SETTINGS.MK |-- Standalone_Build_Preparation.pdf |-- toolchains |   `-- scfw |       `-- gcc-arm-none-eabi-6-2017-q2-update |-- u-boot -> bsp/uboot-imx `-- VERSION.MK -> build/VERSION.MK
View full article
Adeneo Embedded's senior engineer Tristan Lelong has put together this very useful whitepaper which describes the process of using USB loader to program a new i.MX6 platform.
View full article
NXP’s i.MX6UL3 Cortex A7 based power efficient CPU integrates comprehensive security features such as TRNG, Crypto Engine (AES with DPA, TDES/SHA/RSA), Tamper Monitor, Secure Boot, SIMV2/EVMSIM interfaces, OTF DRAM Encryption, PCI4.0 pre-certification etc. This makes the i.MX6UL3 CPU as very ideal solution for the electronic point of sale (ePOS) applications. iWave Systems being one of the early adaptor of the i.MX6UL CPU, launched cost effective i.MX6UL3 based SOM for POS applications where power consumption, small form factor and security features are very critical. The IMX6UL3 SOM module is equipped with 256MB of DDR3 RAM, which is expandable up to 1GB. 256MB of NAND flash is supported on the SOM which is also expandable higher memory configuration. All the IO peripheral interfaces supported by imx6 ultra lite CPU is available through 200 pin SODIMM edge connector. i.MX6UL SODIMM Module By using the proven i.MX6UL3 SOM, a POS unit can be quickly realized by developing an application specific base board with the following features; EMV compliant Smart card, magnetic swipe reader, Thermal Printer, key pad, Finger print sensor, TFT display, 2G/3G module, Wi-Fi/BT modules, NFC reader, Micro SD card, USB OTG and battery support. iWave’s i.MX6UL development board can be used for quick POS prototyping and application development. The development kit includes Imx6ul3 SOM module,base board with multiple USB ports, Micro SD, RGB display, camera port, audio In/Out, multiple UARTs, PWM interface, I2C, GPIOs etc.This is ideal starter kit for connecting all the necessary POS specific interface modules and quick prototyping of POS application. You can kick start your POS product design with this Industry latest i.MX6UL3 SOM now by ordering the i.MX6UL development board from the following link; http://www.iwavesystems.com/product/development-platform/i-mx6ul-development-kit.html​
View full article
This blog post will present the architecture of the i.MX6SoloX and i.MX7D processors and explain how to build and run the FreeRTOS BSP v1.0.1 on the MCU. Both processors are coupling a Cortex-A with a Cortex-M4 core inside one chip to offer the best of MPU and MCU worlds (see i.MX7D diagram). Content below will apply for our Nit6_SoloX and Nitrogen7 platforms. For the impatient You can download a demo image from here: 20160804-buildroot-nitrogen6sx-freertos-demo.img.gz for Nit6_SoloX 20160804-buildroot-nitrogen7-freertos-demo.img.gz for Nitrogen7 As usual, you’ll need to register on our site and agree to the EULA because it contains NXP content. The image is a 1GB SD card image that can be restored using zcat and dd under Linux. ~$ zcat 20160804-buildroot*.img.gz | sudo dd of=/dev/sdX bs=1M For Windows users, please use Alex Page’s USB Image Tool. This image contains the following components: Linux kernel 4.1.15 U-Boot v2016.03 FreeRTOS 1.0.1 demo apps Please make sure to update U-Boot from its prompt before getting started: => run clearenv => run upgradeu After the upgrade, the board should reset, you can start your first Hello World application on the Cortex-M4: => run m4update => run m4boot Architecture As an introduction, here is the definition of terms that will be used throughout the post: MCU: Microcontroller Unit such as the ARM Cortex-M series, here referring to the Cortex-M4 MPU: Microprocessor Unit such as the ARM Cortex-A series, here referring to the Cortex-A9/A7 RTOS: Real-Time Operating System such as FreeRTOS or MQX The i.MX6SX and i.MX7 processors offer an MCU and a MPU in the same chip, this is called a Heterogeneous Multicore Processing Architecture. How does it work? The first thing to know is that one of the cores is the "master", meaning that it is in charge to boot the other core which otherwise will stay in reset. The BootROM will always boot the Cortex-A core first. In this article, it is assumed that U-Boot is the bootloader used by your system. The reason is that U-Boot provides a bootaux command which allows to start the Cortex-M4. Once started, both CPU are on their own, executing different instructions at different speeds. Where is the code running from? It actually depends on the application linker script used. When GCC is linking your application into an ELF executable file, it needs to know the code location in memory. There are several options in both processors, code can be located in one of the following: TCM (Tightly Coupled Memory): 32kB available OCRAM: 32kB available If not using the EPDC, 128kB can be used but requires to modify the ocram linker script DDR: up to 1MB available QSPI flash (not available for ou Nit6_SoloX): 128kB allocated on Nitrogen7 Note that the TCM is the preferred option when possible since it offers the best performances since it is an internal memory dedicated to the Cortex-M4. External memories, such as the DDR or QSPI, offer more space but are also much slower to access. In this article, it is assumed that every application runs from the TCM. When is the MCU useful? The MCU is perfect for all the real-time tasks whereas the MPU can provide a great UI experience with non real-time OS such as GNU/Linux. We insist here on the fact that the Linux kernel is not real-time, not deterministic whereas FreeRTOS on Cortex-M4 is. Also, since its firmware is pretty small and fast to load, the MCU can be fully operating within a few hundred milliseconds whereas it usually takes Linux OS much longer to be operational. Examples of applications where the MCU has proven to be useful: Motor control: DC motors only perform well in a real-time environment since feedback response time is crucial Automotive: CAN messages can be handled by the MCU and operational at a very early stage Resource Domain Controller (RDC) Since both cores can access the same peripherals, a mechanism has been created to avoid concurrent access, allowing to ensure a program's behavior on one core does not depend on what is executed/accessed on the other core. This mechanism is the RDC, it can be used to grant peripheral and memory access permissions to each core. The examples and demo applications in the FreeRTOS BSP use RDC to allocate peripheral access permission. When running the ARM Cortex-A application with the FreeRTOS BSP example/demo, it is important to respect the reserved peripheral . The FreeRTOS BSP application has reserved peripherals that are used only by ARM Cortex-M4, and any access from ARM Cortex-A core on those peripherals may cause the program to hang . The default RDC settings are: The ARM Cortex-M4 core is assigned to RDC domain 1, and ARM Cortex-A core and other bus masters use the default assignment (RDC domain 0). Every example/demo has its specific RDC setting in its hardware_init.c. Most of them are set to exclusive access. The user of this package can remove or change the RDC settings in the example/demo or in his application. It is recommended to limit the access of a peripheral to the only core using it when possible. Also, in order for a peripheral not to show up as available in Linux, it is mandatory to disable it in the device, which is why a specific device tree is used when using the MCU: imx7d-nitrogen7-m4.dts The memory declaration is also modified in the device tree above in order to reserve some areas for FreeRTOS and/or shared memory. Remote Processor Messaging (RPMsg) The Remote Processor Messaging (RPMsg) is a virtio-based messaging bus that allows Inter Processor Communications (IPC) between independent software contexts running on homogeneous or heterogeneous cores present in an Asymmetric Multi Processing (AMP) system. The RPMsg API is compliant with the RPMsg bus infrastructure present in upstream Linux 3.4.x kernel onward . This API offers the following advantages: No data processing in the interrupt context Blocking receive API Zero-copy send and receive API Receive with timeout provided by RTOS Note that the DDR is used by default in RPMsg to exchange messages between cores. Here are some links with more details on the implementation: RPMsg_RTOS_Layer_User's_Guide.pdf https://www.kernel.org/doc/Documentation/rpmsg.txt Where can I find more documentation? The BSP actually comes with some documentation which we recommend reading in order to know more on the subject: FreeRTOS_BSP_1.0.1_i.MX_7Dual_Release_Notes.pdf FreeRTOS_BSP_for_i.MX_7Dual_Demo_User's_Guide.pdf FreeRTOS_BSP_i.MX_7Dual_API_Reference_Manual.pdf Getting_Started_with_FreeRTOS_BSP_for_i.MX_7Dual.pdf Build instructions Development environment setup In order to build the FreeRTOS BSP, you first need to download and install a toolchain for ARM Cortex-M processors. ~$ cd && mkdir toolchains && cd toolchains ~/toolchains$ wget https://launchpad.net/gcc-arm-embedded/4.9/4.9-2015-q3-update/+download/gcc-arm-none-eabi-4_9-2015q3-20150921-linux.tar.bz2 ~/toolchains$ tar xjf gcc-arm-none-eabi-4_9-2015q3-20150921-linux.tar.bz2 ~/toolchains$ rm gcc-arm-none-eabi-4_9-2015q3-20150921-linux.tar.bz2 FreeRTOS relies on cmake to build, so you also need to make sure the following packages are installed on your machine: ~$ sudo apt-get install make cmake Download the BSP The FreeRTOS BSP v1.0.1 is available from our GitHub freertos-boundary repository. ~$ git clone https://github.com/boundarydevices/freertos-boundary.git freertos ~$ cd freertos Depending on the processor/board you plan on using, the branch is different. For Nit6_SoloX (i.MX6SX), use the imx6sx_1.0.1 branch. ~/freertos$ git checkout origin/imx6sx_1.0.1 -b imx6sx_1.0.1 For Nitrogen7 (i.MX7D), use the imx7d_1.0.1 branch. ~/freertos$ git checkout origin/imx7d_1.0.1 -b imx7d_1.0.1 Finally, you need to export the ARMGCC_DIR variable so FreeRTOS knows your toolchain location. ~/freertos$ export ARMGCC_DIR=$HOME/toolchains/gcc-arm-none-eabi-4_9-2015q3/ Build the FreeRTOS apps First, here is a quick overview of what the FreeRTOS BSP looks like: All the applications are located under the examples folder: examples/imx6sx_nit6sx_m4/ for Nit6_SoloX examples/imx7d_nitrogen7_m4/ for Nitrogen7 As an example, we will build the helloworld application for Nitrogen7: ~/freertos$ cd examples/imx7d_nitrogen7_m4/demo_apps/hello_world/armgcc/ ~/freertos/examples/imx7d_nitrogen7_m4/demo_apps/hello_world/armgcc$ ./build_all.sh ~/freertos/examples/imx7d_nitrogen7_m4/demo_apps/hello_world/armgcc$ ls release/ hello_world.bin hello_world.elf hello_world.hex hello_world.map The build_all.sh script builds both debug and release binaries. If you don't have a JTAG to debug with, the debug target can be discarded. You can then copy that hello_world.bin firmware to the root of an SD card to flash it. Run the demo apps Basic setup First you need to flash the image provided at the beginning of this post to an SD Card. The SD Card contains the U-Boot version that enables the use of the Cortex-M4 make sure to update it as explained in the impatient section. By default, the firmware is loaded from NOR to TCM. You can execute m4update to upgrade the firmware in NOR. It will look for file named m4_fw.bin as the root of any external storage (SD, USB, SATA) and flash it at the offset 0x1E0000 of the NOR: => run m4update If you wish to flash a file named differently, you can modify the m4image variable as follows: => setenv m4image While debugging on the MCU, you might wish not to write every firmware into NOR so we've added a command that loads the M4 firmware directly from external storage. => setenv m4boot 'run m4boot_ext' Before going any further, make sure to hook up the second serial port to your machine as the one marked as "console" will be used for U-Boot and the other one will display data coming from the MCU. In order to start the MCU automatically at boot up, we need to set a variable that will tell the 6x_bootscript to load the firmware. To do so, make sure to save this variable. => setenv m4enabled 1 => saveenv This blog post only considers the TCM as the firmware location for execution. If you wish to use another memory, such as the OCRAM or QSPI or DDR, you can specify it with U-Boot variables. => setenv m4loadaddr => setenv m4size Note that the linker script must be different for a program to be executed from another location. Also, the size reserved in NOR right now is 128kB. Hello World app The Hello World project is a simple demonstration program that uses the BSP software. It prints the "Hello World" message to the ARM Cortex-M4 terminal using the BSP UART drivers. The purpose of this demo is to show how to use the UART and to provide a simple project for debugging and further development. In U-Boot, type the following: => setenv m4image hello_world.bin => run m4update => run m4boot On the second serial port, you should see the following output: Hello World! You can then type anything in that terminal, it will be echoed back to the serial port as you can see in the source code. RPMsg TTY demo This demo application demonstrates the RPMsg remote peer stack. It works with Linux RPMsg master peer to transfer string content back and forth. The Linux driver creates a tty node to which you can write to. The MCU displays what is received, and echoes back the same message as an acknowledgement. The tty reader on ARM Cortex-A core can get the message, and start another transaction. The demo demonstrates RPMsg’s ability to send arbitrary content back and forth. In U-Boot, type the following: => setenv m4image rpmsg_str_echo_freertos_example.bin => run m4update => boot On the second serial port, you should see the following output: RPMSG String Echo FreeRTOS RTOS API Demo... RPMSG Init as Remote Once Linux has booted up, you need to load the RPMsg module so the communication between the two cores can start. # modprobe imx_rpmsg_tty imx_rpmsg_tty rpmsg0: new channel: 0x400 -> 0x0! Install rpmsg tty driver! # echo test > /dev/ttyRPMSG The last command above writes into the tty node, which means that the Cortex-M4 should have received data as it can be seen on the second serial port. Name service handshake is done, M4 has setup a rpmsg channel [0 ---> 1024] Get Message From Master Side : "test" [len : 4] Get New Line From Master Side RPMsg Ping Pong demo Same as previous demo, this one demonstrates the RPMsg communication. After the communication channels are created, Linux OS transfers the first integer to FreeRTOS OS. The receiving peer adds 1 to the integer and transfers it back. The loop continues infinitely. In U-Boot, type the following: => setenv m4image rpmsg_pingpong_freertos_example.bin => run m4update => boot On the second serial port, you should see the following output: RPMSG PingPong FreeRTOS RTOS API Demo... RPMSG Init as Remote Once Linux has booted up, you need to load the RPMsg module so the communication between the two cores can start. # modprobe imx_rpmsg_pingpong imx_rpmsg_pingpong rpmsg0: new channel: 0x400 -> 0x0! # get 1 (src: 0x0) get 3 (src: 0x0) get 5 (src: 0x0) ... While you can send the received data from the MCU on the main serial port, you can also see the data received from the MPU on the secondary serial port. Name service handshake is done, M4 has setup a rpmsg channel [0 ---> 1024] Get Data From Master Side : 0 Get Data From Master Side : 2 Get Data From Master Side : 4 ... That's it, you should now be able to build, modify, run and debug
View full article
i.MX6 Q7 Development Kit       The Development Platform incorporates Q7 compatible i.MX6 SOM which is based on Freescale’s i.MX 6 Series 1.2GHz multimedia focused processor and Generic Q7 compatible Development 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 onboard connectors to validate complete i.MX6 CPU features.   Benefits Simple, low cost and yet rugged assembly thanks to the industrial temperature grade and compact (120 x 120 - Nano ITX) form factor Simple and low-cost integration thanks to the on-board standard interfaces (uSD, USB and Memory) Lowest power consumption. Typical power consumption      Highlights Ideal for quick development Shortens product development life cycle Quick customization can be done in a very shorter period Suitable for validation of any R1.20 Q7 compatible module      Features Display: 7" 800x480 TFT LCD, VGA Port/ TV Out, HDMI Port*, LVDs Display connector* Touch Panel: Resistive Touch Capacitive touch* Video Input: Camera Interface*, TV IN* Audio: External Audio Codec, Headphone/ Mic Jacks PCIe: PCIe Mini Card*, PCIex1 Port* USB: USB2.0 Device - Mini AB connector, USB2.0 Host 2 ports - Type A Connector Serial: UART - DB9 connector Storage: SATA Port1 - 7P Connector*, SATA Port2 - 22P Connector*, Standard SD Slot Communication: 10/100Mbps Ethernet - RJ45 Jack, 802.11b/g/n Wi-Fi Module*, CAN Port - DB9 connector* Power: 12V DC Input, On-board RTC coin Battery Form Factor: 120 x 120 - Nano ITX Temperature supported: 0 to 60 oC      Target Applications Industrial/Medical Green Energy Controller Panel PC, High-end PDAs, Secure Devices, Industrial appliance Control, Automotive In Vehicle Infotainment Systems Medical HMI, Kiosks, POS, General Embedded     Click here for more details on the i.MX 6 Q7 Development Kit by iWave
View full article
Hello i.MX6 Users, We have created a innovative application wherein you can create a i.MX6 dual lite hardware design as per your customised requirement in a minute. Creating a new design is super easy where you need to add the processor, peripheral requirements and the board input power input to the application. With these input requirements the application will 1. Find peripheral , power, clock, reset and power sequencing components 2. Find processor pin mux options 3. Optimise the power, clocks 4. Generate the design and draw the schematic to be viewed online. It is a powerful algorithm meant exclusively for high end processors like i.mx6. You can generate any number of designs using our application hosted at www.circuit-tree.com. We will shortly be expanding our library and also add more form factors to support different hardware designs. Let us know if you have any questions/concerns/feedback. Thanks Circuit tree team
View full article
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
View full article
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
View full article
The FSL Community BSP 1.6 has been released featuring several updates including: Yocto Project 1.6 support Integration of 3.10.17-1.0.0 GA release for i.MX6 platforms U-Boot 2014.01 Linux Kernel 3.14 For the detailed announcement, please check: https://lists.yoctoproject.org/pipermail/meta-freescale/2014-May/008490.html
View full article
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  
View full article
Freescale i.MX6 UltraLite processor, 528MHz Up to 1GB DDR3 and 32GB on-board eMMC Dual-band 802.11a/b/g/n WiFi and BT 4.1 BLE Ethernet, 5x USB, 8x UART, 2x CAN, SDIO, 78x GPIO Miniature size - 36 x 68 x 5 mm                CL-SOM-iMX6UL​ is a tiny System-on-Module (SoM) / Computer-on-Module (CoM) board designed to serve as a building block in embedded applications. CL-SOM-iMX6UL is build around the Freescale i.MX6 UltraLite system-on-chip featuring an advanced Cortex-A7 ARM CPU. The SoC is coupled with up-to 1GB DDR3 and 32GB of on-board eMMC storage. The processor is supplemented with up-to 4GB DDR3 and 32GB of on-board SSD. Measuring only 36 x 68 x 5 mm CL-SOM-iMX6UL features a wide range of industry standard interfaces - Ethernet, WiFi 802.11, Bluetooth, USB, CAN bus, serial ports, I/O lines and ADC inputs. Low price makes CL-SOM-iMX6UL an ideal selection for cost-sensitive systems, while its small size and low power consumption facilitate integration into portable and space-constrained designs. CL-SOM-iMX6UL is provided with comprehensive documentation​ and full ready-to-run SW support for Linux operating system. CL-SOM-iMX6UL Detailed Spec​ CL-SOM-iMX6UL Block Diagram​ CL-SOM-iMX6UL Development Kit​ CL-SOM-iMX6UL Online Pricing​
View full article
As many customers find it difficult selecting an Operating system for their next product on a given platform Adeneo Embedded put together a very detailed comparison between Linux and WEC7 on the i.MX53 platform. This comparison documents everything from the time it takes to setup the platform, create the first builds to performance and power consumption benchmarks. Below is a snapshot of the contents of the document.   To get access to the complete document, please contact Adeneo Embedded at sales@adeneo-embedded.com
View full article
e-con Systems launches the 13MP Autofocus 4-lane MIPI camera board for NXP i.MX6. This camera is based on 1/3.2" AR1335 CMOS image sensor with advanced 1.1µm pixel BSI technology from ON Semiconductor® and an integrated high-performance image signal processor (ISP) that performs all the Auto functions (Auto White Balance, Auto Exposure control). Target Applications Kiosk Documents Reader/Scanner Unmanned Aerial Vehicles (UAVs) Autonomous Robotic Systems Mobile Medical Imaging Intelligent Video Analytics (IVA) Features Benefits Advanced 1.1µm pixel BSI technology Delivers superior low-light image quality and produces accurate color reproduction 1080p @80 fps - YUV422 High quality HD video playback Interlaced High Dynamic Range (iHDR) Allows to capture clear images in both extreme lighting conditions Pan Tilt Digital Zoom(Upto 8x) Allows to get a closer view of far-away objects Autofocus Allows users to reliably and easily maintain sharp focus on subjects as they move throughout the frame
View full article
iWave Systems launched Industry's latest Pico ITX Board around Freescale Semiconductor’s i.MX 6 Solo/Dual Lite processor which is iWave’s 4th design based on i.MX6 CPU. Pico-ITX is the industry’s smallest motherboard form factor which inspires innovative system designs and allows Single Board Computers to be accessible for a new generation of smaller computing and connecting devices. Measuring just 10cm x 7.2cm, iWave’s i.MX6 SBC is a highly integrated platform for increased performance in “Intelligent Industrial Control Systems, Industrial Human Machine Interface, Ultra-Portable Devices, Home Energy Management Systems and Portable Medical Devices”. iMX6 Pico ITX SBC Board iWave’s Pico ITX SBC is based on  i.MX6 Dual Lite/Solo based dual/single core ARM Cortex™-A9 core which can operate up to 1GHz with 2D/3D graphics accelerators, 1080p video encode & decode, and integrated power management. The design is also compatible with i.MX6 Quad & Dual processors. The platform is designed keeping extended temperature in mind, which can operate form -20C to +85C temperature range. The i.MX6 Pico ITX SBC supports the following features;  CPU: i.MX6 Dual Lite/Solo, (Quad /Dual compatible) RAM: 512MB DDR3 (Expandable up to 2GB) PMIC: Freescale MMPF0100 Debug Console: RS232 to USB Micro-AB connector USB OTG connector Dual USB Host Connector Micro SD Slot (default boot device) Standard SD/SDIO Slot 10/100/1000Mbps Ethernet Half mini PCIe card connector HDMI Port LVDS connector with Backlight 4-wire Resistive Touch controller AC97 Audio Codec with Audio Out Jack & Audio In Header 8bit CMOS Camera Connector 2 Lanes MIPI Camera connector CAN1 Header 4 Position user  Dip Switch & status LEDs Optional eMMC Support Optional SATA 7pin Connector 80mils Expansion Header-84 pin           o MIPI DSI  SPI CSI0 Camera interface CAN2 Interface UART s- 3 Ports I2C- 3 Ports GPIOs Optional LVDS1 interface Optional MLB 6pin & 3 pin signals Power Input: 5V, 2A (2.5mm Jack) Form factor: Pico ITX (100 x 72mm) Operating temperature range:  -20°C to +85°C OS Support: Linux 3.0.35, Android 4.0*, WEC7* The Pico ITX module will be supported for minimum 7 years. :smileyinfo: http://www.iwavesystems.com/product/development-platform/i-mx6-pico-itx-sbc/i-mx6-pico-itx-sbc.html Email: mktg@iwavesystems.com iWave Launches Industry's first i.MX6 SoloDual Lite based Pico-ITX Single Board Computer - YouTube
View full article
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/
View full article