i.MX Solutions Knowledge Base

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

i.MX Solutions Knowledge Base

Labels
  • General 294

Discussions

Sort by:
Product Features: SMARC Development kit pre-loaded with Android OS Kit includes: (1). REV-SA01 SMARC Evaluation Carrier Board in 3.5" SBC Form Factor (2). SMA-IMX6QI Quad Core SMARC Module (3). Power Adapter: AC Input: 100-240V DC Output: 5.0V (4). Power Cable (5). Mini-USB Cable (6). Pre-loaded OS on onboard eMMC
View full article
Dear i.MX Partners,   The i.MX  technical support team understands the importance of supporting effort towards establishing a vast and valuable ecosystem for i.MX products.  We are here to help you!  If you have technical questions or encounter problems in the use or development of an i.MX product, please use the following procedure to submit a discussion in the i.MX  Community, and receive priority attention.    In order to be recognized as one of our valued partners, we require that you make your company name visible to “Everyone” in your member profile 2 and add two separate tags 1 to every discussion you create: The word “partner” <Your company‘s name>   Partner support requests will be escalated to i.MX Support team on a high-priority 3 basis.  Valid support requests include questions about, or problems encountered on, our standard products, e.g., BSP, documentation or development platforms.   This invitation is open to all current NXP/i.MX  partner companies, including members of NXP Connect and those in the i.MX Partner Program.  In order to facilitate a clear escalation path, Please use @mention 4 to notify your NXP contacts 5 , so they are aware of your request and can track the status of your issue”   For questions or issues that contain sensitive or confidential information: Create a discussion in the i.MX Community that generically describes the issue or question, and request private support.  A “Private Discussion” (PD) will be initiated by a technical support representative assigned to your issue, and sent to you and any contacts you have @mentioned 4 .  The discussion and response will take place in the PD, invisible to the public.  Upon issue closure, the partner is expected to generically summarize the problem and solution in the original public discussion for the benefit and general education of the community on the issue.   Thank you! NXP Support Community     Footnotes: TAGS are free-form text you can enter in the space designated for tags, or in the body of a discussion prefaced by “#”. For more information, please search for “tags” in the community. This is done by clicking on the down-arrow icon next to your name in the top-right corner of any community page, selecting “Edit Profile & Privacy”, selecting the “Privacy Settings” tab, and then changing the Company Name visibility to “Everyone”. Your discussion will be escalated 6 to an NXP support representative and assigned on a priority basis.  Priority will always be elevated above other community support requests and can be significantly higher based on your status with NXP and your company’s participation level in the i.MX community. @mention is a method where you type “@” followed by the community username of the person you would like to be notified.  For more information, please search for “@mention” in the community. Your NXP contact is a person most familiar with your support request.  It can be your relationship manager, or anyone who has familiarity with your activity.  This will be your inquiry and escalation contact. The escalation and assignment process occurs through a private (invisible) process.  The assigned person will contact you directly if additional information or discussion is required. At this time it is not our standard practice to communicate the assignment.  Please use the NXP contact(s) who were @mentioned 4 in the discussion to provide a status of the issue.  The original discussion will remain in the public community as an opportunity for others to contribute.    
View full article
  Adeneo Embedded's continued investment in the Freescale i.MX6 solutions is proven again. Adeneo Embedded discovered a critical bug in the ARM TLB translation mechanism detailed in the following ARM errata:       ARM: 754322—Possible faulty MMU translations following an ASID switch       We have developed a patch for the Windows Embedded Compact Kernel that fixes this issue on the i.MX6 BSP. We are currently in the validation process of this fix and will be releasing the patch soon.     For early access to the patch and further information please contact sales@adeneo-embedded.com    
View full article
Abstract: Browsers and mobile applications are using WebRTC for audio and video Real-Time Communications (RTC) via simple APIs. The WebRTC components have been optimized to best serve this purpose. WebRTC based web application provides rich, real-time multimedia features (think video chat) on the web, without any plugins, downloads or installs.It’s purpose is to help build a strong RTC platform that works across multiple web browsers, across multiple platforms. iWave has developed WebRTC based Peer to Peer audio and video communication on i.Mx6 Qseven development platform. iWave is using FireFox web browser and its in built webrtc  api’s for the communication. Architecture of WebRTC Detailed Description: iWave’s i.Mx6 Q7 platform has Quad core processor which can operate up to 1 GHz speed/core. i.MX6 CPU is NXP’s latest achievement in integrated multimedia application processors which is part of growing multimedia-focused products that offers high performance processing and are optimized for lowest power consumption. iWave’s i.Mx6 Q7 platform supports 1GB RAM in 64bit mode with eMMC memory of 4GB which can be used both as Mass storage and boot device. i.Mx6 Q7 also supports Ethernet port which is integrated i.Mx6 CPU and connected to the external Gigabit Ethernet PHY on SOM. iWave’s Application consist of two components – clients and server. Peer to Peer communication is done between two clients. Server is used for registering the clients and to keep the necessary set up for two clients to communicate. After setting up, the server is not having any role in the communication. Client Application: Client application is very simple web application using WebRTC to transport audio and video between two clients. The application will enable one client to "dial" the other client and make a video call (with audio).This application only works between two clients. It can be run using Firefox browser Server: The server brokers the initial connection between the two clients. Once a connection is established between the clients, their communication continues in a peer to peer mode: none of the video data is routed through the server. Working Process of WebRTC Peer to Peer communication Audio Codec: Audio codec supported by WebRTC is OPUS codec .OPUS codec Supports constant and variable bit rate encoding from 6 kbit/s to 510 kbit/s, frame sizes from 2.5 ms to 60 ms, and various sampling rates from 8 kHz (with 4 kHz bandwidth) to 48 kHz. The Acoustic Echo Canceler present in WebRTC removes the acoustic echo resulting from the voice being played out into the active microphone. Noise reduction component removes certain types of background noise usually associated with VoIP. Video Codec: Video codec supported by WebRTC is VP8. The VP8 video codec is well suited for RTC since it is designed for low latency. WebRTC has dynamic video jitter buffer for video which conceal the effects of jitter and packet loss on overall video quality. Image enhancement removes the video noise from image captured from camera. WebRTC call: A Screenshot of WebRTC peer to peer audio and video communication Benefits: WebRTC is In-built in Firefox browser. Improved video and audio streaming. VP8 video codec and OPUS audio codec provides much less data transmission without packet loss. WebRTC based Peer to Peer communication can be run from firefox  browser without any plugin or software installation. Audio and Video streaming can be done local networks. For more information please visit: WebRTC Peer to Peer Communication(Audio & Video) on i.MX6 board | iWave Systems or contact mktg@iwavesystems.com
View full article
http://www.youtube.com/watch?v=3_fm1epAr0k&feature=player_embedded   Uploaded by ARMflix on Jan 12, 2012 Freescale's latest innovation in the automotive industry including the next generation GM OnStar product running on the new i.MX 6 Cortex-A9-based processor, automotive infotainment, graphics technology with real-time 3D rendering, and an example of the applicability of i.MX 6 quadcore technology.   www.freescale.com @Freescale Category: Science & Technology License: Standard YouTube License  
View full article
http://www.youtube.com/watch?v=PmHNecNguDM&feature=player_embedded   Uploaded by Charbax on Jun 21, 2011 Here is the board for now, they are going to launch the new Genesi i.MX53 based Laptops and Desktops around July or August, to provide more performance, using lower power and at lower cost. The current Genesi Efika MX i.MX51 based laptop is selling for $199, the Genesi i.MX51 Desktop is $129, they plan for the next generation i.MX53 based Laptop and Desktop to be sold for even cheaper. They are also working to combine their ARM based Laptop with the Pixel Qi screen as soon as it's mass produced. Category: Science & Technology License: Standard YouTube License  
View full article
Adeneo Embedded is proud to announce its collaboration with Emtrion on the Freescale i.MX6 based Industrial CPU Module.  Emtrion GmbH, a company specialised in Embedded Systems design, hardware and software, announces the availability of a new industrial processor module based on the multicore Cortex-A9 i.MX6 SoC family from Freescale. 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. This module will fulfil all requirements for industrial applications as well as multimedia application using its powerful GPU. The DIMM-MX6 module is available in several versions, with either i.MX6 Solo, Dual or Quad and on-board memories ranging up to 8GB for Flash (SLC NAND) and 2GB RAM (DDR3). The module is also qualified for an extended temperature range of -40°C to +85°C.   Adeneo Embedded has jointly developed and maintains Windows Embedded Compact BSP for Emtrion's industrial CPU module design based on iMX6. The combined expertise of both companies on h/w and s/w provides unmatched support to customers in enabling them to move quickly with their designs. Adeneo Embedded continuously updates the BSP with feature updates and improvements. More information about the Freescale products supported by Adeneo Embedded can be found at Board Support Packages / Products / Home - Adeneo Embedded.   Contact Adeneo Embedded at sales@adeneo-embedded.com.   See full version here: https://community.freescale.com/docs/DOC-98468.
View full article
Added by iWavesystems on October 20, 2011 at 7:26am http://www.youtube.com/watch?feature=player_embedded&v=gHiHe5IX5LU#!#!   Uploaded by pressannas on Jun 29, 2011 iW-i.MX53 is a reference platform based on Freescale's i.MX53 (1GHz, ARM Cortex-A8) multimedia application processor. It is the latest addition to iWave's growing family of refernce platforms. G11D provides high performance processing with a high degree of functional integration, aimed at the growing Automative Infotainment, Telematics, HMI and Display based cluster markets. This processor includes 3D and 2D graphics processors, 1080i/p video processing, dual display and provides variety of interface. Category: Science & Technology License: Standard YouTube License  
View full article
ConnectCore for i.MX51 Linux Development Kit Added by Mike Rohrmoser on July 29, 2010 at 7:38pm Digi JumpStart Kit for Digi Embedded Linux  
View full article
DSC_0061 Added by iWavesystems on November 21, 2011 at 7:49am    
View full article
on Embedded World 2011 Added by Ramona Maurer on November 13, 2011 at 8:47am emtrion presented the new module based on i.MX53 on Embedded World 2011  
View full article
(无显示点网页快照)QQ /微信963146376,办理国外毕业证成绩单,各国大学学历认证,实体公司高效办理,真实可靠,视频认证,安全无忧! 主营业务一,快速办理高仿毕业证成绩单: 1,毕业证+成绩单+留学回国人员证明+教育部学历认证(全套留学回国必备证明材料,给父母及亲朋好友一份完美交代); 2,雅思,托福,OFFER,在读证明,学生卡等留学相关材料(申请学校,转学,甚至是申请工签都可以用到)。 注:上述高仿材料,随时都可以安排办理,毕业证成绩单,学校,专业,学位,毕业时间都可以根据客户要求安排。 办理流程: 1,收集客户办理信息; 2,客户付定金下单; 3,公司确认到账转制作点做电子图;电子图做好发给客户确认; 5,电子图确认好转成品部做成品; 6,成品做好拍照或者视频确认再付余款; 7,快递给客户(国内顺丰,国外DHL)。 主营业务二,真实教育部学历认证 1,教育部学历学位认证,留服官网真实存档可查,永久存档。 2,留学回国人员证明(使馆认证),使馆网站真实存档可查。 办理流程 客户提供相关材料,确定客户办理信息,给出最佳操作方案; 2,补充毕业证成绩单等相关材料; 3,留服官网注册申请账号,付定金; 4,预约递交时间,公司人员陪同客户本人一起去留服递交材料; 5,等待结果,完成结果书留服直接邮寄给客户 6,客户确认收到结果,付余款。 客服微信:963146376 QQ:963146376 澳洲Monash毕业证修改成绩单莫纳什大学毕业证@微Q:963146376留信网认证办理莫大、Monash莫纳什大学假文凭、Monash University 办澳洲Monash毕业证修改成绩单莫纳什大学毕业证@微Q:963146376留信网认证办理莫大、Monash莫纳什大学假文凭、Monash University 办澳洲Monash毕业证修改成绩单莫纳什大学毕业证@微Q:963146376留信网认证办理莫大、Monash莫纳什大学假文凭、Monash University 办澳洲Monash毕业证修改成绩单莫纳什大学毕业证@微Q:963146376留信网认证办理莫大、Monash莫纳什大学假文凭、Monash University
View full article
Developer Kit i.MX53 Added by Ramona Maurer on March 28, 2012 at 10:51am   Developer Kit from emtrion also available with Linux and QNX
View full article
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/
View full article