Technologic Systems carries a full spectrum of off-the-shelf products powered by the NXP/Freescale i.MX 6 ARM CPU including single board computers, computer-on-modules, and touch panel PCs.  Read about it in their iMX6 Boards, Modules, and Touch Panels Portfolio​ page.  The portfolio features off-the-shelf products: TS-4900 High Performance WiFi & Bluetooth Enabled 1 GHz i.MX6 Computer-on-Module TS-7970 WiFi & Bluetooth Enabled 1 GHz i.MX6 Single Board Computer TS-TPC-7990 7" Capacitive or Resistive Touch Panel PC TS-TPC-8950-4900 10'' High Performance Mountable Touch Panel PC TS-8550 TS-SOCKET Development Baseboard All i.MX6 products come with a choice of Linux, Windows, Android, or QNX operating system, have a plethora of industry standard connections, industrial temperature ranges, and long lifecycle guarantee.  If an off-the-shelf solution doesn't quite match your needs, custom hardware and software engineering services are also available. Thanks, Derek Hildreth eBusiness Manager Technologic Systems www.embeddedarm.com About Technologic Systems Technologic Systems has been in business for 32 years, helping more than 8000 OEM customers and building over a hundred COTS products that have never been discontinued. Our commitment to excellent products, low prices, and exceptional customer support has allowed our business to flourish in a very competitive marketplace. We offer a wide variety of single board computers, computer-on-modules, touch panel computers, PC/104 and other peripherals, and industrial controllers that satisfy most embedded project requirements. We also offer custom configurations and design services. We specialize in the ARM and X86 architectures, FPGA IP-core design, and open-source software support, providing advanced custom solutions using hardware-software co-design strategies.

iWave Systems launched two additional SOMs based on i.MX 6QuadPlus (iMX6QP) and i.MX 6DualPlus(iMX6DP) adding to its existing i.MX6 SOM portfolio.  The new i.MX6QP and i.MX6DP CPUs from NXP provide increased memory bandwidth without any major changes in the software and hardware. This provides 90% enhancement in the memory efficiency compared to i.MX6Q / i.MX6D. The 2D and 3D graphic engine performance of these new QP and DP devices are improved more than 50% compared to the predecessors- i.MX6 Quad and Dual core devices. Check the performance improvements of i.mx6QP / i.mx6DP device here. iWave Systems launched the i.MX6 QuadPlus and DualPlus CPU based Qseven compatible System On Modules (SOMs) at the same time as NXP launched the i.MX6 QP/DP chipsets. These modules are supported with Linux and Android BSP support. More information about imx6QP / imx6DP modules can be found here.

We have a new i.MX283 / i.MX287 SODIMM sized SOM, the CFA-10036: Here are the features that set this module apart: Debug/Console OLED, 128x32 pixels, I2C interface microSD socket to allow huge non-volatile storage at low cost microUSB connector supplies power and console through gadget driver i.MX283 version: 128MB DDR2, 91 GPIO i.MX287 version: 256MB DDR2, 126 GPIO Only a single 5v supply is needed Support included in Linux 3.7 mainline kernel Open software, fully documented hardware This module has a very low cost of entry. At the minimum level, all you need to use it is the module itself and a standard microUSB cable. We also have a debug/prototyping board that adds wired Ethernet and USB A connectors, as well as a generous prototyping area: For the initial production we have this as a project on Kickstarter: CFA-10036 Open, Hackable, Linux + ARM Embedded GPIO Module Please contact CFA10036@crystalfontz.com for production inquiries. | Crystalfontz America, Incorporated | 12412 East Saltese Avenue | Spokane Valley, WA 99216-0357 | http://www.crystalfontz.com | voice (509) 892-1200 fax (509) 892-1203 US toll-free (888) 206-9720

iWave Systems Technologies, successfully demonstrated the MIPI camera on its latest i.MX6 Qseven development kit. The Leopard’s 5M pixel MIPI CSI Camera module part LI-OV5640-MIPI-AF is integrated with the latest revision of iWave i.MX6 Q7 evaluation board and the sensor supports the following features. Sensor: OV5640 (CMOS image sensor) Active array Size: 2592x1944 Image transfer rates; 1080p@30fps, 720p@60fps Module Connector: AXK824145   The camera is interfaced with the i.MX6 processor through MIPI CSI interface. The Linux 3.0.35 and Android 4.0.4 BSP support is available for this display with iWave’s i.MX6 development kit. The i.MX6 development board integrated with this MIPI camera is available for shipping now. About i.MX6 Qseven Development Board: The Development Platform incorporates Qseven compatible i.MX6x SOM which is based on Freescale's iMX 6 Series 1.2GHz multimedia focused processor and Generic Q7 compatible Evaluation Board. This platform can be used for quick prototyping of any high end applications in verticals like Automotive, Industrial & Medical. Being a nano ITX form factor with 120mmx120mm size, the board is highly packed with all necessary on-board connectors to validate complete iMX6 CPU features. About i.MX6 Qseven System On Module (SOM): iW-RainboW-G15M is Freescale's i.MX6 based Qseven compatible CPU module for faster and multimedia focused applications. The module has on-board expandable 1GB DDR3 RAM, micro SD slot and optional eMMC flash. With the extreme peripheral integration, the module supports industry latest high performance interfaces such as, PCIe Gen2, Gigabit Ethernet, SATA 3.0, HDMI 1.4 and SDXC etc. About iWave Systems: iWave has been an innovator in the development of “Highly integrated, high-performance, low-power and low-cost i.MX6/i.MX50/i.MX53/i.MX51/i.MX27 SOMs”. iWave helps its customers reduce their time-to-market and development effort with its products ranging from System-On-Module to complete systems. The i.MX6 Pico ITX SBC is brought out by iWave in a record time of just 5 weeks. Furthermore, iWave’s i.MX6/i.MX50/i.MX53/i.MX51/i.MX27 SOMs have been engineered to meet the industry demanding requirements like various Embedded Computing Applications in Industrial, Medical & Automotive verticals. iWave provides full product design engineering and manufacturing services around the i.MX SOMs to help customers quickly develop innovative products and solutions. For more details: i.MX6 Q7 Development Kit | iWave Systems email: mktg@iwavesystems.com

The wait is over! Toradex announces the launch of its latest technical support feature, the Toradex Community, an online community that aims to provide customers a unique platform to stay connected with the Toradex engineers. Toradex, which has always provided extensive free and direct technical support from development engineers, recognizes that many of its customers often have similar queries. By providing an online community where anyone may post a query and by publicly listing down the engineers’ responses, Toradex anticipates that the entire community will stand to benefit from the collective knowledge available via the forum. “We invested a lot of time to understand what information our customers most wanted access to and how to deliver it in a simplified, user friendly and timely manner. With the launch of the Toradex Community platform, our aim is to create an even more connected and responsive support system for our customers, while enabling easy access to information. We invite you to be a part of this ever-growing community constituted by our embedded enthusiasts.” said Roman Schnarwiler, CTO, Toradex. The community will serve to provide its members with sustainable solutions and key insights from our experienced engineers who will be answering queries related to the usage of Toradex products in a wide variety of embedded applications. Furthermore, it will complement the exhaustive information available on the Toradex Developer Center, which is a resourceful website that brings all of Toradex’s developer resources together at one place. For an overview about all our available support channels, please check our support page. About Toradex: Toradex is a leading vendor of ARM based System on Modules (SOMs) that can be used for diverse embedded applications. Powered by Freescale® i.MX 6 & Vybrid™, NVIDIA® Tegra, and other leading processors, the SOM families offer a wide range of options in terms of price, performance, power consumption and interfaces. Complemented with the long-term availability of 10+ years for its products, Toradex stands out in the embedded computing market with free lifetime product maintenance, pin-compatible product families for scalable designs, direct premium technical support, and transparent pricing with direct online sales. Founded in 2003 and headquartered in Horw, Switzerland, the company’s network stretches across the globe with additional offices in the USA, Vietnam, China, India, Japan, and Brazil. For more information, visit https://www.toradex.com. For media queries, please contact: Lakshmi Naidu: lakshmi.naidu@toradex.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

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, check out this video that demonstrates software making use of power savings capabilities on the i.MX28:  http://go.mentor.com/low-power

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

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

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