Michel's blog

Working with Visual Studio 2015 in combination with Platform Builder on a 4K monitor is very frustrating. The Attach Device window always opens half outside the display area on the bottom right, the Callstack window has such tiny letters that you need to use a magnifier to be able to read it, and Visual Studio 2008 is completely unworkable because the entire IDE reverts to tiny letters as soon as you download your kernel.

I tried the compatibility wizard to no avail and had given up hope, until one of our experts found the solution!

Start regedit, browse to [HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers] and add a new string value with the path to devenv.exe, then set the value to "~ DPIUNAWARE" and Visual Studio and all your Platform Builder specific windows will work as they do on a normal, non-4K monitor!

We have finalized testing and have now published official release 1375 of the GuruCE i.MX6 BSP. This release again adds a lot of great new features and improvements all of our customers will be very happy to see.

Some highlights:

Updated GPU driver to v5.0.15

Improved load, flash and boot times by up to 50%

Added support for LZ4 compressed kernel binaries to the bootloader.

Optimized bootloader cache settings (L1/L2) to shorten boot time.

Bootloader boot delay can now be set to 0 to shorten boot time.

Now setting ARM CPU frequency according to speed grade in the bootloader.

Made many improvements in the BSP catalog to make it even easier to use.

Added support for storage profiles per USDHC instance. This means that SD cards always get mounted using the same folder name, no matter in what order they are inserted, and we can now specify exactly which USDHC port to store the hive-based registry on or exactly which USDHC port to mount as root.

Added support for NXP SDB-QP (QuadPlus) board.

Added support for Device Solutions Opal6-QP (QuadPlus) board.

USB OTG Client/Host auto-detection now working correctly on all boards.

Added TinyBoot bootloader. This is an SPI bootloader that just resets the i.MX6 and directs it to boot from the medium selected in the catalog.

Pictures say more than a thousand words, so here are some highlights of this release captured on video:

Even though the GuruCE i.MX6 BSP is already the best performing, 100% OAL stable and most feature-rich i.MX6 BSP on the market today, there are always things to improve or fix and new features to implement.

Changed condition for enabling L2 cache double line fill feature to depend on L2C-310 revision. The i.MX6Solo/DualLite and DualPlus/QuadPlus now all have r3p2, so for those processors the double line fill feature is now enabled, resulting in much better cache behaviour (and better realtime performance on those processors).

Even though the GuruCE i.MX6 BSP is already the best performing, 100% stable and most feature-rich i.MX6 BSP on the market today, there are always things to improve or fix and new features to implement.

Here's our wishlist:

Reduce power consumption and enable super low power modes (DVFS/suspend)

We have finalized testing and have now published official release 954 of the GuruCE iMX6 BSP. This release adds a couple of great new features many of our customers have been wanting to see supported in our BSP.

Reduce power consumption and enable super low power modes (DVFS/suspend)

As always; if you have anything you want us to add to the list or you want us to prioritize an item on the list: contact us and we'll make it happen.

In case you did not see it yet, the video below highlights some of the features of our previous BSP release. We'll create a new video highlighting the new release features (like bootsplash and multi-monitor) soon.

Windows 10 is coming! Quickly in fact. It’ll be here July 29th, 2015 and that leaves very little time to get ready. You may have seen an article or two on the 6 versions of Windows 10 but I’m going to cover all 10 editions. In the past 8 months, I’ve attended a ton trainings on Windows 10 and visited the Redmond Campus 6 times. Microsoft has been upfront about Windows 10 and they have provided information on a monthly basis, but the time has come – it’s here and it “IS” the O/S you will want moving forward!

10 VERSIONS OF WINDOWS 10

The news recently covered 6 or 7 versions of Windows 10 but most articles were leaving out the embedded (now called IoT) family of products. If you include the OEM Embedded versions, you jump to the wonderful count of 10 different flavors of Windows 10. See the Full list below.

Windows 10 Home – Non Domain for Home Users focused on Consumers

Windows 10 Pro – Domain connected for Business and Expert users.

Windows 10 Enterprise – A Volume upgraded edition that adds Corporate Security and other Features

.Net Micro Framework – Free and Open Source with support for very low-end ARM devices.

THE PRICE

Free! Well not for every version and for a limited time but let me explain: Consumer and OEM System Builder versions will be a free “Upgrade” from Windows 7 and Windows 8.1 editions where you have a legal license.

What about the Embedded (IoT) family of Windows 7 and Windows 8.1 products – do they qualify for the upgrade? It depends. The FES family known as the For Embedded Systems products because they are 100% bit for bit identical to the full Windows products, will be eligible for the free upgrade. As long as those FES devices are connected to the internet and have Windows Updates enabled, they will get the free upgrade notification allowing them to be upgraded for free to Windows 10 Pro. However the WES and POS/Industry family would not qualify for this limited time free upgrade.

What about the Enterprise Volume license space for Win7 and Win 8.1? At this time the answer is no. Many customers who use the Enterprise Volume license typically have Software Assurance and if you have activate SA then you would in fact be getting the rights to Windows 10 Enterprise but only if your SA is active.

ELEVATOR PITCH – What’s it get me if I upgrade?

Most importantly it gets you a familiar user experience that your users will already be comfortable in using. Secondly it gets you the ability to run not only all your Win32/Win7/Win8 applications but it also adds a new Universal Application platform that allows the Apps written to work on all Windows 10 devices across device sizes including Xbox One, Windows Phone, Tablets, Desktops and even the new Surface Hub – 80” Display. It has improved security with the new “Hello” biometrics and face recognition capability as well as new DirectX12 graphic performance enhancements. They’ve also added a new Modern Browser called “Edge” that will compete with top Browsers on the market while keeping the IE11 version for backwards compatibility. Lastly, for a period of one year the product is free for consumer home use so I suggest you download it today or reserve you free copy via Windows Update.

EMBEDDED IoT OEM’s – What’s in it for me?

To start with a very simplified roadmap and a product family that has a unified toolset which gets you the ability to write applications once then run them across the entire Windows 10 family of devices. If you are building a small x86 or Arm device with low specifications you can use the Windows 10 IoT for Core devices which is now a free license. If you are building a device that requires more horsepower and would already have the Windows shell then you have the simplified choice of Windows 10 IoT for Enterprise/Industry devices. One part number and family to work with and one toolkit to work with.

HOW TO GET IT TODAY

Signup for the Tech Preview and look within your MSDN Subscription as the latest build is available via the MSDN download site. Lastly, watch for the Windows 10 reserve your copy balloon notification if you have a Windows 7 Pro/Ult or Windows 8.1 Pro system with the latest updates. It arrives July 29th. Get the Preview today from here: http://windows.microsoft.com/en-us/windows/preview-iso

THE EMBEDDED IOT CONCERN

If you built your OEM appliance using the For Embedded System versions of Windows 7 Pro/Ult or Windows 8.1 Pro and the device is connected to the internet with updates enabled you need to beware that the Windows 10 Free upgrade notifications have officially started. It means your device could very well be displaying a notification to users to reserve the Windows 10 upgrade which will go live July 29th. Most OEMs probably do not want this notification to be displayed on their appliance nor would they want the end-user to upgrade the device to Windows 10 because the application would not have been tested on Windows 10 and could break the appliance.

The latest information provided to our Embedded OEMs help set a registry key that will block any O/S upgrades. You can use group policy (which sets a registry key) or you can use the key directly. The group policy already exists on any PC which installed these KBs: Windows 7 SP1 – KB3050265 or Windows 8.1 Update – KB3050267.

It is called “Turn off the upgrade” to the latest version of Windows through Windows Update. If the group policy is set, then an OS Upgrade will never be detected, downloaded, or installed on that PC. The OS Upgrade applicability will look at the Policy registry key that’s set when you enable that policy:

This update also installs a new group policy that allows you to block upgrades to the latest version of Windows through Windows Update. Computers with this policy applied will never detect, download or install an upgrade to the latest version of Windows.

Policy setting: Turn off the upgrade to the latest version of Windows through Windows Update (enabled, disabled)

IOT ACTIVATION

Embedded OEMs love WES7 because it had by-pass activation built into the product. If you have a device that you did not want to connect to the internet then WES7 was a great choice. Flash forward to Windows 10 and now with the Windows 10 IoT Enterprise edition you will receive a single PID/Key and your device will run without any activation notifications as long as it is not connected to the internet. If you do connect it to the internet then it will attempt to activate and will do so in the background without Windows 10 IoTany notifications. It’s a quiet type method of activation.

SINGLE TOOLKIT FOR ALL EDITIONS – WICD

Windows Image Configuration Designer – pronounced “Wicked” is the new tool that has been heavily simplified and covers all editions. Download it today and start practicing with the new tool.

I’ll close by suggesting again that you go download the latest Tech Preview and start testing. I’ve been running the Tech Preview since last November and it is proving to be the edition where Microsoft listened to the users and developers. It’s the edition to move your projects toward.

NINJA CAT

The Ninja Cat meme has been embraced by Windows Insiders everywhere as well as Microsoft. To learn more and download a copy of a Ninja Cat image for your device check out this article.

About the Author
Based in Phoenix, Ariz., Ken Marlin is a Microsoft MVP and Microsoft Champion at Avnet Embedded. He has over 25 years of Microsoft experience supporting all Microsoft products and programs with specialties in Microsoft OEM Embedded appliances as well as OEM System Builder and Volume programs. Ken is very passionate about technology in general and is also a Game Master for the annual Avnet Tech Games Competition. He is a first time contributor to the GuruCE blog. More about Ken here.

Boundary Devices, a leading global supplier of ARM-based single board computers and System-on-Modules for the general embedded market, and GuruCE, well-known manufacturer of high quality Microsoft Windows Embedded Compact BSPs, today announced their official partnership.

GuruCE fully supports Boundary Devices' iMX6 based single board computers and SOMs in their very popular iMX6 BSP for Windows Embedded Compact 7 and 2013.

“GuruCE has put together an impressive CE7 and CE2013 BSP for i.MX6. The performance enhancements, features, and stability are ideal for embedded customers who are looking to use Windows Embedded Compact in their product. The GuruCE team has demonstrated a high-level of expertise with Windows Embedded Compact and is a great software partner that we highly recommend”

Pejman Kalkhoran, Partner at Boundary Devices.

“Boundary Devices popular and high quality SBCs and SOMs are a valuable addition to our GuruCE iMX6 BSP range of supported boards”

Michel Verhagen, CEO of GuruCE.

About GuruCE
GuruCE offers deep technical knowledge of Windows Embedded Operating Systems. The consultants of GuruCE are among the best in Windows Embedded BSP & driver development, training and consulting. They help customers overcome the steep learning curve and greatly reduce the time-to-market for their products. GuruCE operates as an umbrella for the top 5% of talented Windows Embedded consultants and employs local experts in Europe (Netherlands), USA and New Zealand. For more information please visit https://guruce.com

About Boundary Devices
Boundary Devices is a leading global supplier of ARM-based single board computers and System-on-Modules for the general embedded market. Founded in 2003 and headquartered in Chandler, AZ, Boundary Devices is a Freescale Proven Partner and have completed numerous successful projects with the I.MX family of processors. All boards are manufactured in the USA by specialists service providers in accordance with modern quality standards. All hardware is designed and tested in our Chandler, AZ facility. Software is always a barrier in embedded designs. With a significant amount of software partners as well as high-level internal expertise, Boundary Devices is well-positioned to provide the right software solution for your embedded design. For more information visit http://boundarydevices.com/

We've received reports of problems with our demo kernels on boards with a rev 1.0 iMX6 CPU. If you encounter problems, please first check the CPU revision of the iMX6 on your board.

You can do this by breaking into the bootloader menu, type 'B' to get to the bootloader shell, then type 'i' followed by ENTER and check the number after 'Revision'. If this number is smaller than 1.1 you will not be able to successfully run our demo kernels on your board. Press 'x' or 'q' followed by ENTER to exit the bootloader shell.

The reason we do not support revision 1.0 iMX6 CPUs is simply because we do not have any board with a rev 1.0 CPU on-board, and thus have not been able to test our BSP with rev 1.0 CPUs. If you have an old board and want us to add support for rev 1.0 CPUs, please contact us.

This means you can plug in a 1360x768 monitor and have the CE desktop shown in that resolution, then unplug the monitor and plug in a 1920x1080 monitor and CE will dynamically change resolution and show the desktop in 1920x1080 resolution, all this of course without the purple line on the left (a long standing problem in all the other iMX6 BSPs available).

HDMI, LVDS and LCD display output is now configurable in the bootloader

This means we have one kernel image for all. Just go into the bootloader menu and select which display you are using at which resolution and launch the kernel. Simple as that!

Added support for DMA on all UARTs

Full RX & TX DMA support on UART1, 2, 3, 4 and 5.

Upgraded to the latest Vivante GPU GALCORE driver v5.0.11 (25762)

And we added all the tutorials and test code as well. Together with the amazing performance increase of this release you can now enjoy 110+ fps in full screen 1920x1080 (and 350+ fps windowed) for OpenGL-ES 1.1/2.0! The OpenVG spinning tiger sample is now so fast you only see a blur, and we fully support OpenCL on Dual and Quad of course.

This is not nearly as low as we would like, but it's a lot better already. Our next release will focus on power-consumption and heat generation reductions.

Improved network performance

The performance improvements also make Ethernet throughput a lot better. We're only halfway to reaching the theoretical maximum possible on the iMX6 of ~45 MByte/s (it's on our list of things to fix), but at least Ethernet speeds are out of the KByte range now (tested using NETIO on WEC7 & WEC2013):
NETIO - Network Throughput Benchmark, Version 1.32
(C) 1997-2012 Kai Uwe Rommel

If you have installed an SDK generated from a WEC2013 OS Design built on a system that has the April 2015 update installed, you will most probably encounter this error when trying to compile a native code project targeting the SDK:

Further analysis shows that -1073741515 in unsigned hex is 0xC0000135 and that value is defined as error STATUS_DLL_NOT_FOUND in Windows:

#define STATUS_DLL_NOT_FOUND ((NTSTATUS)0xC0000135L)// winnt

So, something is missing a DLL somewhere...

A compare with an SDK installation generated prior to the installation of the April 2015 WEC update showed that the folder C:\Program Files (x86)\Windows CE Tools\SDKs\[SDK Name]\Sdk\Bin\i386\Arm was missing the file mspdb110.dll. Copying this file manually to the aforementioned folder fixes the problem and you can successfully build the project again.

If you are still getting errors (like for instance "Fatal Error C1902") after having copied mspdb110.dll, then copy all files from the folder "C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE" to the SDK's i386\Arm folder as per above instructions.

This seems to be a problem with the SDK roller introduced in the April 2015 WEC2013 update.

Microsoft is aware of the bug and will most likely fix this issue in the next update of WEC2013.

We also did some work on the bootloader (now you can disable the watchdog in the CE kernel from the bootloader, you can test memory and you can inspect some technical info about image defines, clock gates & frequencies and the iMX6 itself). The problem we had with Ethernet on some Sabre-Lite boards has been fixed and UART DMA is now working properly as well, as is ILTiming. While we were at it, we also slightly improved the real-time performance of the kernel and we fixed some dependencies in the catalog.

All in all another great release from the experts at GuruCE! Go ahead and download a WEC7 or WEC2013 evaluation kernel for one of the many supported off-the-shelf development kits and SBCs.

PRESS RELEASE:
Hoehenkirchen-Siegertsbrunn, Germany, and Ohiwa, New Zealand, June 2015

Lauterbach, leading manufacturer of microprocessor development tools, and GuruCE, well-known manufacturer of high quality Microsoft Windows Embedded Compact BSPs, announced a deepening of their relationship in the form of an official partnership between GuruCE and Lauterbach. The experts at GuruCE and Lauterbach already have a long working relationship that is now brought to an even higher level of cooperation.

Lauterbach's debugging expertise combined with GuruCE's Windows Embedded expertise has been critical in creating a highly reliable and extremely well performing iMX6 BSP for Windows Embedded Compact 7 and 2013.

GuruCE now ships easy-to-use Lauterbach JTAG scripts with their iMX6 BSP so that GuruCE's customers can, if needed, dive deep with the help of the best JTAG solutions for Windows Embedded Compact by Lauterbach.

“We at Lauterbach very much enjoy the cooperation with GuruCE. Close contacts between the developers and managers of both companies ensure a fast time-to-market of new solutions, as well as a rapid response to customer support issues”, said Rudi Dienstbeck at Lauterbach.

“The expertise of Lauterbach has been invaluable in tracking down some very complex issues with L1 and L2 cache coherency in the multi-core iMX6 processors. Without the excellent support & tools of Lauterbach it would have taken us much longer to create a fully multi-core cache-coherent BSP for the iMX6”, said Michel Verhagen at GuruCE.

About GuruCE
GuruCE offers deep technical knowledge of Windows Embedded Operating Systems. The consultants of GuruCE are among the best in Windows Embedded BSP & driver development, training and consulting. They help customers overcome the steep learning curve and greatly reduce the time-to-market for their products. GuruCE operates as an umbrella for the top 5% of talented Windows Embedded consultants. Most of the experts working with us are Microsoft MVPs. GuruCE employs local experts in Europe (Netherlands), USA and New Zealand. For more information please visit https://guruce.com

About LAUTERBACH
Lauterbach is the leading manufacturer of complete, modular and upgradeable microprocessor development tools worldwide with experience in the field of embedded designs since 1979. It is an international, well-established company with blue chip customers in every corner of the globe and has a close working relationship with all semiconductor manufacturers. At the headquarters in Höhenkirchen, near Munich, the engineering team develops and produces highly proficient and specialized Development Tools, which are utilized all over the world under the brand TRACE32®. Own branch offices exists in United Kingdom, Italy, France, Tunisia, on the East and West coasts of the United States, Japan and China. Highly qualified sales and support engineers are also available in many other countries. For more information visit http://www.lauterbach.com/

Congratulations! We are pleased to present you with the 2015 Microsoft® MVP Award! This award is given to exceptional technical community leaders who actively share their high quality, real world expertise with others. We appreciate your outstanding contributions in Windows Embedded technical communities during the past year.

According to my profile this is now the 12th consecutive year but I think that must be at least 13 (2001 or maybe 2002 was the first if I remember correctly). So long time MVP I can't even remember, but: Very happy to be recognized in the field again!

Both Michel Verhagen and Erwin Zwart of GuruCE are Microsoft Embedded Most Valuable Professionals; a recognition of their expertise and community involvement in the field of Windows Embedded Compact.

After working for more than a year on our iMX6 BSP we are finally ready to put our quality stamp on it and release our iMX6 BSP to our customers!

Here are the main benefits of our iMX6 BSP compared to the other iMX6 BSP offerings on the market today:

Stability

Our initial iMX6 BSP release is all about stability. We have done extensive testing to make sure the entire BSP is stable, in multi-core and single-core configurations, with or without caching, at stress and at rest. We have completely rewritten all of the low-level initialization code, all the timing code (CCM, system & performance counters), all of the cache code, all of the SMP (symmetric multiprocessing/multi-core) code and most of the interrupt handling code.

Performance

We have implemented all the cache optimizations possible for the iMX6 Cortex-A9 in combination with the PL310 L2 Cache Controller and we have configured DDR3 per board at the most optimal, fully stress tested, settings.

No more data corruption!

We have done extensive testing to make sure there are no more data corruption problems when copying large files (on SATA, USB Storage or USDHC) or when sending large amounts of data over the network.

One BSP for all iMX6 variants

Our BSP supports the iMX6 Solo, Dual Lite, Dual and Quad processor range, so you can scale your HW design up or down without any software development investment!

One BSP supporting WEC7 and WEC2013

Full drop-in support for WEC7 and WEC2013. Not a single code change required in the BSP.

Super easy BSP configuration

Very easy configuration of board, bootloader, CPU, cache and page table BSP options through the catalog (see image on the right).

Production Quality Code

All hardware definitions name-synchronized with the iMX6 Reference Manuals and IOMUX tool. A large amount of Freescale code re-factored, cleaned up & bug fixed, and all redundant code removed and restructured. No more searching for driver code distributed throughout the BSP in different folders. Now the BSP is easily maintainable, well-structured & production ready. If you have worked with BSPs from Freescale or some of our competitors before you know what this means and why this is so important. Code quality and BSP structure is everything!

Full source

Including all Cortex-A9 cache routines, SMP, drivers, etc.
We just don't believe in binary. Luke would never have gotten so far if he had to "use the binary"... ;-)

Very easy to add support for your custom board

All board specific settings in one folder and board file generator included. All you need to support your custom board is an IOMux design file (created with Freescale's IOMux tool for iMX6) and our board file generator that will create a header file with all your board specific settings.

SPI Flash/SD/MMC Bootloader

Our iMX6 bootloader offers many more configuration options and features, like selecting the serial debug port to use, blowing fuses, configuring the Ethernet settings to be used in Windows Embedded Compact and starting the kernel with a clean registry hive. It also fully supports booting from SPI Flash, SD and MMC, and has full support for formatting and partitioning SD and MMC and erasing/writing SPI Flash.

Full support for LCD8000-97C 1024x768 LVDS + capacitive touch screen

The BSP includes full support for this display, including touch driver support.

Hive based registry support

Destination fully configurable through the catalog. No registry modifications required.

GPIO driver + SDK library

Control any (free) GPIO pin from your application.

FlexCAN driver + SDK library

Fully configurable FlexCAN driver. Access and control 2 separate CAN buses from your application with full configuration and timing control. Our High Performance FlexCAN driver for real busy CAN buses is available for iMX6 as well.

ECSPI driver + SDK library

Fully configurable, DMA enabled, Enhanced Configurable SPI driver. All functionality offered by the iMX6 is supported and configurable in our driver. Unfortunately the iMX6 still contains the same silicon bug as on the iMX53, but at least our driver warns you when you hit this condition.

GPT driver

Use the General Purpose Timer from within your application. Full control over counters, interrupts, etc.

USB Camera driver

Configured and ready for iMX6.

Memory Access Utility driver, SDK and application

For easy debugging and direct hardware access from within CE. Similar functionality as memtool in Linux.

The low-level kernel initialization code takes care of everything needed by Windows Embedded Compact. It does not depend on any configuration done by the bootloader. This means you can choose whatever bootloader you fancy. You can use our included and feature-rich eboot, or any other bootloader you like better.

Supporting the BD-SL-iMX6 (formerly known as SABRE-Lite) board by Boundary Devices (iMX6 Quad)

Our business model
Our business model is all about delivering a high quality BSP that we fully support and stand behind. We want our customers to be able to get to market quicker, without having to spend an enormous amount of time and money on finding and fixing bugs. We sell & support a high quality, tested BSP and if needed our customers can work with GuruCE to add additional functionality or modify functionality specific to the customers needs.

Dedicated & responsive support from real experts!
You connect directly to the highest level support engineers that will respond to your query within 48 hours with a high quality answer that will help you, not frustrate you.

Is it perfect?
Perfection is something we strive to achieve, but we will not pretend our BSP is perfect. There's always something to improve or functionality to add. This initial release was completely focused on stability and performance. Our next update will add some functionality (PCIe) and focus mostly on power management.

Get the cores to the lowest possible power state when in idle to further reduce power dissipation and CPU heat. The first step is to reduce power dissipation in the low power WAIT mode, the next step will be to implement STOP mode, the step after will be to add DVFS support, and the final step will be to make sure the entire system can suspend and resume correctly.

Add support for more boards

Add support for Nitrogen6X, Freescale SDP, Digi CC6, Variscite iMX6 SOMs and possibly more iMX6 boards and modules available from various board and module manufacturers.

Rewrite entire ENET driver

So we fully support NDIS6 and can increase performance.

Rewrite I2C driver

Currently functional, but we would love to add more functionality and create high quality, maintainable code.

Rewrite IPU driver

Currently functional, but we would love to add more functionality so we can support true multi-monitor, dynamic resolution, dynamic switching of output, etc.

Update: We have repeated our tests on iMX6 and unfortunately the same silicon bug is also present on the iMX6, so everything you read here can be applied to the iMX6 as well...

We recently did a full rewrite of the Freescale ECSPI driver for our Opal i.MX53 BSP (now fully supporting all ECSPI features; master/slave mode, DMA, etc) and during testing we discovered a rather big problem with the ECSPI module inside the i.MX53...

For future reference and to prevent others from having to go through the same time-consuming research and analysis we decided to publish our findings through this blog post.

Problem Analysis

The ECSPI module shows unexpected behaviour when the bitcount is set to [(32 * n) + 1], where [n > 0].

As an example, let's walk through sending 1 x 33 bits.

In this case, we have to load the TXIFO with 2 UINT32s. The first UINT32 value contains 1 LSB and the 2nd UINT32 contains the remaining 32 bits.

Freescale's response

We of course asked Freescale to verify this bug and they have. This is their response:

We are able to reproduce it. Unfortunately, there's no workaround for this error.

Other i.MX CPUs affected by this silicon bug?

We have verified the i.MX25 is NOT affected by this bug (but the i.MX25 contains an older version of the SPI block).We have not been able to try our tests on the i.MX6 yet, but since the i.MX6 contains the exact same ECSPI block as the i.MX53, we suspect this issue will also be present on the i.MX6 series CPUs.
The issue is also present on the iMX6.

We have asked Freescale to update the errata sheets for the affected processor(s), but so far the erratas are silent about this issue.

More ECSPI silicon bugs?

Unfortunately; yes. Also the RX DMA TAIL mechanism (allowing non 32-word aligned DMA transfers to complete) does not work correctly. Here is the official response from Freescale:

We have confirmed this with the SDMA script owner. The script does not support the 32bytes unaligned DMA transfer.
This is a documentation bug. This will be corrected on documentation on next release.

Interesting way to solve silicon bugs... ;)

Conclusion

The ECSPI module inside the iMX53 CAN NOT BE USED for SPI transfers on 32 bit edges + 1.

GuruCE has been working on a high quality iMX6 BSP for WEC2013 since the beginning of 2014, and will be releasing this BSP early 2015.

Microsoft has just released a SAMPLE BSP for iMX6 through Update 11 for WEC2013, so why would you wait for the GuruCE iMX6 BSP? Here are some compelling reasons:

One BSP for all iMX6 variants

Our BSP supports the iMX6 Solo, Dual Lite, Dual and Quad processor range, so you can scale your HW design up or down without any software development investment!
We are contemplating to add support for iMX6 Solo Lite as well. Please let us know if you are interested in having this!

Production Quality Code

All hardware definitions name-synchronized with the iMX6 Reference Manuals and IOMUX tool. Almost all Freescale code re-factored, cleaned up, bug fixed, redundant code removed and restructured. Now the BSP is easily maintainable, well-structured & production ready. If you have worked with BSPs from Freescale or some of our competitors before you know what this means and why this is so important. Code quality and BSP structure is everything!

Full source

Including DVFS, GPC, Cache routines, SMP, PCIE and PMU code.
We just don't believe in binary. Luke would never have gotten so far if he had to "use the binary"...

Very easy to add support for your custom board

All board specific settings in one folder and board file generator included. All you need to support your custom board is an IOMux design file (created with Freescale's IOMux tool for iMX6) and our board file generator that will create a header file with all your board specific settings.

Lots of added functionality and fixes:

GPIO driver + SDK library

Control any (free) GPIO pin from your application.

FlexCAN driver + SDK library

Fully configurable FlexCAN driver. Access and control 2 separate CAN buses from your application with full configuration and timing control. Our High Performance FlexCAN driver for real busy CAN buses is available for iMX6 as well.

So, you've just updated your Visual Studio 2013 and WEC2013 installations and have generated an SDK for your OS Design. Now you install the SDK and you get this error message: "You must install Windows Embedded XAML Tools before you can proceed with this SDK installation."

Very annoying, and this is something that started being a problem with one of the later (post Update 5) updates for WEC2013. I did not have time to figure out exactly what is causing this issue (most probably some mismatching version information of the XAML toolset), but I did find a workaround:

Use Orca (or any other msi editor) to remove the Custom Action named "CA_CheckPreReqWEXTInstalled".

Orca is in the Microsoft Windows SDK which should be on your machine if you've installed Visual Studio. Take a look in your "Program Files (x86)" folder and search for "orca". You should find "Orca-x86_en_us.msi", or something similar (depending on what VS version you have installed). If you can't find anything make sure to install Visual Studio or download the Microsoft Windows SDK here.

Once you've installed Orca you can right click the SDK msi and choose "Edit with Orca". When Orca opens you'll have to select the "CustomAction" table on the left and select the row with action "CA_CheckPreReqWEXTInstalled":

Now press the delete key and a dialog should pop up asking you if you really want to permanently remove this row from the database:

Click OK, save the modified msi and exit Orca.

Now the SDK will install without problems.

DISCLAIMER: This is a workaround, not a final solution. I'm pretty sure it will all work just fine with the latest (mismatching version number) XAML tools, but I haven't checked it. Please let me know if you find any issues with this workaround by leaving a comment below, thanks!

[This is an update of a blog post I wrote a long time ago. Check the comments under that post if you have any questions (or comment on this post if your question is not answered in the old post)]

A question that keeps coming back on the forums is "I changed some code, but it does not end up in my image", or "I changed some registry values in platform.reg, but if I look at the device registry, it's not there!", or even "Why does a kernel build take so long?".

The source of these problems is build-related. You've got to understand the build system in order to know exactly what to do. This blog post aims to give you a clear handle on "What to build when"!

At first glance, WEC2013 seems to only offer two build command: "Build Solution" and "Rebuild Solution". There are however a lot more variations that can save you a tremendous amount of time in your day-to-day work with Visual Studio 2013 and Platform Builder.

Before we dive into build system commands and how to use them I'd like to make sure you understand you should never modify code in the PUBLIC or PRIVATE trees. If you need to change functionality in those code trees it is very important you clone that code to your BSP folder or OS Design folder first. The main reason is that changing code in the PUBLIC or PRIVATE folder will not result in the code changes to be automatically build and included in your kernel image. You'd have to manually build that code, make sure the updated libraries, dlls and/or exes are in the right place, and then rebuild your kernel. The reason why this can cause many problems is because any WEC update may overwrite your code changes and maintenance is a nightmare.

So, keep this in mind:

Never change code in the PUBLIC or PRIVATE trees; always clone to your BSP or OS Design first!

In all the versions before WEC2013 Microsoft included build commands in the Advanced Build menu that would execute "blddemo" without the "-q" parameter. This results in the ENTIRE WINCEX00 tree being built, thereby overwriting many libraries, DLLs and EXEs that shipped as binary with CE/EC. After years of protest by all the embedded MVPs we finally managed to convince MS that these commands should be erased from the IDE. However, you can of course still execute blddemo without -q on the command line. This command is, and always has been, very dangerous because sometimes the binaries do not match the actual source code. This can happen when an update updates some libraries, but not the source code. This *should* not happen, but it does happen over and over again. Executing "blddemo" without the "-q" parameter will result in your CE tree being in an undetermined state and the only solution is a complete uninstall and reinstall of CE/EC. So, if you're working from the command line; NEVER EVER execute blddemo without the -q parameter! If you're not working from the command line; no worries!

Phew! Now that we got that out of the way let's see what build command we've got to use in what situation:

WEC2013 Build Commands

Create a new OS Design (or add a new build configuration to an existing OS Design): Sysgen (Build Solution)

Since a new OS Design doesn't have anything in its build configuration's output folders (same with a new build configuration) you'll have to sysgen the entire solution (for that build configuration). The longest process, but luckily you don't have to do this many times (see below).

Change Platform Settings: Make image

If you change any Platform Settings (like IMGNOKITL, IMGNODEBUGGER, IMGPROFILER) all you have to do is a Make Image.

Change driver source code in your BSP: Build the driver and Make Image

If you change driver source code, all you have to do is just build the driver (WINCEREL must be set to 1 but it is set by default so unless you changed it there's no need to worry) and do a makeimg. If you only want to debug the driver you can also add the DLL to the Release Directory Modules list (menu Tools) and just restart the device (or reload the device driver on the device) without having to do a makeimg and download to device. Building just the driver is a simple right-click on the driver and Build in the IDE or "build" in the driver's folder on the command line.

The safe option, this way you can't forget to rebuild anything. Building the BSP is a simple right-click on the PLATFORM\BSP folder and Build in the IDE or "build" in the BSP's root folder on the command line.

A lot of steps, but this will still not take longer than a couple of minutes. If you change any of the platform.* files we need to re-filter (Sysgen) those files and make sure the filtered files are copied into the FLATRELEASEDIR (Copy Files to Release Directory). That last action did however clear the project binaries from the FLATRELEASEDIR so we need to make sure those binaries and settings are getting copied into the FLATRELEASEDIR again (Build All Subprojects) and finally we are ready to Make Image. Now your registry changes will be in the image (check reginit.ini to make sure, last entry wins).

Change some source files and platform.reg, bib, dat or db files in your BSP: Build and Sysgenthe BSP, Copy Files to Release Directory, Build All Subprojects and Make Image

Only difference with previous situation is that you now have to build the BSP to include the source code changes.

The "Build and Sysgen BSP" command can be executed by right clicking your BSP root node in the Solution Explorer and choosing "Build and Sysgen (cebuild -qbsp)". Notice the -q in that command? That shows you it's a good command...

For most components a simple Sysgen is enough. For some components (like when changing from RAM based registry to Hive based Registry) a Clean Sysgen is needed. This action takes the longest (anywhere from 5 minutes for a small workspace configuration on a very fast machine to a couple of hours for a really big configuration and a very slow machine). A Sysgen is a right-click on the workspace, Advanced Build Commands->Sysgen in the IDE or "blddemo -q" on the command line.

To make sure all components are re-linked with the (possibly updated) libraries a Clean Sysgen is needed. This action takes the longest (anywhere from 5 minutes for a small workspace configuration on a very fast machine to a couple of hours for a really big configuration and a very slow machine). A Clean Sysgen can be performed by choosing Rebuild Solution from the build menu, or choosing Advanced Build Commands->Clean Sysgen in the IDE or "blddemo clean -q" on the command line.

Sometimes it's easier to build from the command line. If you are unsure what command to type you can always perform the action in the IDE first and watch the 3rd line in the build output window starting with "Starting Build:". Behind the colon is the exact command line for that action, eg Sysgen on the BSP: "Starting Build: SysgenPlatform %_TARGETPLATROOT% preproc&&SysgenPlatform %_TARGETPLATROOT% postproc", so on the command line you would type "SysgenPlatform %_TARGETPLATROOT% preproc" followed by enter and the 2nd command "SysgenPlatform %_TARGETPLATROOT% postproc" followed by enter.

If you use the commandline, make sure you never forget "-q" when running "blddemo"!

I hope this blog post will help you speed up your builds and lower your frustration with the build system!

PS. Also check out this tip (works for WEC2013 too) to further improve build speed if your BSP is using code from the PLATFORM\COMMON\SRC\SOC folders.

In all the drivers and applications we develop here at GuruCE, we always take the time to add plenty of logging because we know good logging will save us loads of time debugging our code (not that we ever have to debug code here of course... ;)).

Windows CE has a really great mechanism for debug logging called Debug Zones. This mechanism allows you to divide your debug messages into 16 zones and each of these zones can be turned on or off at run-time. This allows you to control the verbosity of your debug output and helps prevent cluttering of messages. Read this excellent blog post by Travis first before reading on: http://blogs.msdn.com/ce_base/archive/2006/12/18/debug-messages-and-debu...

To add debug logging using Debug Zones to your application or driver do the following:

Sounds easy (and actually it is) but to make it more easy (and because we found ourselves doing the same thing over and over) we created a template we now use in all our driver and application code, even on projects targeted for Desktop Windows. Even though "Big" Windows doesn't have a "Debug Zone" mechanism you can still use the template. The big benefit of course being that your code is completely portable between desktop PC's and CE devices (and also MBS/UNICODE)! The only thing you can't do is switch debug zones at run-time, but you can still select which zones should be on or off at compile-time.

We have released these templates under GPL for the greater good.

Let us explain the template by walking through it; we'll start with DebugZones.cpp (the line numbers reflect the actual line numbers in the template files):

#include <windows.h>

#include "DebugZones.h"

// Do NOT change anything in this file.

// See DebugZones.h for things you can change!

/*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*/

extern "C" DBGPARAM dpCurSettings =

{

__WMODULE__,

{

ZONE0_TEXT, ZONE1_TEXT, ZONE2_TEXT, ZONE3_TEXT,

ZONE4_TEXT, ZONE5_TEXT, ZONE6_TEXT, ZONE7_TEXT,

ZONE8_TEXT, ZONE9_TEXT, ZONE10_TEXT, ZONE11_TEXT,

ZONE12_TEXT, ZONE13_TEXT, ZONE14_TEXT, ZONE15_TEXT

},

#ifndef DEBUG // IN RETAIL...

RETAILZONES

#else //IN DEBUG...

DEBUGZONES

#endif

};

The first and most important thing to note is that you should not change anything in this file. You configure the template all through the header file, which we'll will be discussing later.

In this first part of DebugZones.cpp we simply define a global variable dpCurSettings of type DBGPARAM and fill the structure with defines from DebugZones.h. The __WMODULE__ corresponds to the "lpszName" member, the ZONEx_TEXT defines fill the "rglpszZones" array and finally RETAILZONES or DEBUGZONES (depending on whether you build a "debug" or "release" version of the code) corresponds to the "ulZoneMask" member of the DBGPARAM structure. The CE debug system uses this structure to get Debug Zone information from the module and to set or clear debug zones during execution of the module. When you use the template for code targeted at Desktop Windows this structure will only be used by the DEBUGMSG/RETAILMSG macros (they use the ulZoneMask member as a display condition).

#ifndef UNDER_CE

#include <stdio.h>

void WINAPIV NKDbgPrintf(LPCTSTR lpszFmt, ...)

{

#define BUFFER_SIZE 1000

va_list argptr;

va_start(argptr, lpszFmt);

TCHAR szBuffer[BUFFER_SIZE];

_vstprintf_s(szBuffer, BUFFER_SIZE, lpszFmt, argptr);

OutputDebugString(szBuffer);

va_end(argptr);

}

#endif

This code is only used when you target Desktop Windows. Only Windows CE defines NKDbgPrintf so for Desktop Windows we had to create our own implementation of this function to make the Debug Zones system portable. This function simply takes a format string followed by a variable number of parameters and transforms that into a formatted string and outputs it to the debug output window of Visual Studio. Note that the maximum length of the formatted string is BUFFER_SIZE characters.

// Helper function for runtime conversion of char* to _T

LPCTSTR to_T(LPCSTR pStr)

{

#define MAX_CALLS 4

#define MAX_MSG 500

static TCHAR buffer[MAX_CALLS][MAX_MSG];

static DWORD index =0;

LPCTSTR pszRet = buffer[index];

size_t conv;

#ifdef UNICODE

mbstowcs_s(&conv, buffer[index], MAX_MSG, pStr, MAX_MSG);

#else //ANSI

strcpy_s(buffer[index], MAX_MSG, pStr);

#endif

index++;

if (MAX_CALLS==index)

index =0;

return pszRet;

}

This next bit of code is a helper function that solves a problem when you want your code to be portable between MBS and UNICODE. MBS is multi-byte string, also called ANSI string, and UNICODE is, well, UNICODE strings. Let's say you are compiling for UNICODE but want to display a multi-byte string using a function that uses a format string. The way to do that is to use %S instead of %s in the format string. When you use %s in code compiled for UNICODE the variable indicated by %s should be in UNICODE. When you compile for MBS the variable indicated by %s should be MBS. In other words, %s indicates the "native" string format. If you want to display a multi-byte string in code compiled for UNICODE you'd use %S, and if you want to display a UNICODE string in code compiled for MBS you'd use %S as well. In other words, %S indicates the "opposite" string format. And here lies the problem: What if you want to display a multi-byte string regardless of whether the code is compiled for MBS or UNICODE?

You only get the output of the first line! So what just happened? Well, the _vstprintf_s function in NKDbgPrintf expected the first argument to be of the opposite string format. Since you compiled for MBS this means it expects a UNICODE string. The _vstprintf_s function detects it is not and bails out, setting szBuffer to an empty string.

I can hear you say: So why don't you just use _T() in that 2nd call to NkDbgPrintf? And yes, you are right, in the above code that would work, but what if it's a variable pointing to a multi-byte string? You can't use _T() around a variable:

NKDbgPrintf(_T("IPAddress \"%s\"\r\n"), to_T(inet_ntoa(ipAddress)));

Line 67 defines the maximum number of times you can call this function before it will start overwriting its internal buffers. Increase this value if you want to use more than 4 parameters that need to be converted in one call. To understand this, see the following code and its output:

This is the part of the template you should change to match your driver or application. First, in line 33, change the __MODULE__ define to the name of your driver or application. If you are creating a flash driver you'd set this to "FLASH" for instance.

Uncomment line 36 and/or 37 to generate a DEBUGCHK whenever you use ERRMSG and/or WRNMSG. You'd usually only uncomment these lines when you are in the development stage (when you're still actively debugging your code).

Next, in lines 40 to 55, you define the friendly names of the debug zones you want. These names will show up when you use the Debug Zones dialog or the "zo" command from Platform Builder. The predefined ones are always useful:

Init

Use this zone to display debug messages during the initialization phase of your driver. I use this zone in the Init function of drivers.

Function

This zone is used to display function entry and exit. Used by the FUNC_ENTRY and FUNC_EXIT macros (I'll discuss those later)

Memory

This zone is used to display memory allocation and de-allocation. Having a separate zone for memory really helps in identifying memory leaks or memory related problems in your driver or application (besides CeDebugX)

Info

This zone is used to display general information. I use this zone a lot through-out my code and enabling this zone usually means I get heaps of debug messages, but also heaps of information about the flow of my code

Warning

Use this zone for non-fatal errors (also known as warnings ;o)

Error

Use this zone for fatal errors; situations where you had to abort a certain operation

Another zone I use often is "IOCTL". If my driver handles custom IOCTLs I use that zone to display information when those IOCTLs are handled. If you want to add the IOCTL zone you'd change line 43 to:

#define ZONE3_TEXT _T("IOCTL")

Lines 58 to 73 define the actual zone IDs. You use these defines as the first parameter of LOG_MSG (that I'll discuss later) to indicate the zone this message belongs to. After you added the IOCTL zone to the friendly names list, you'd change line 61 to:

#define ZONE_IOCTL DEBUGZONE(3)

Lines 76 to 91 define the zone masks. You use these defines to indicate which zones should be enabled by default. After you added the IOCTL zone to the zone ID list, you'd change line 79 to:

#define ZONEMASK_IOCTL ZONEMASK(3)

Line 93 and 94 define the default zones to use in a release build and a debug build. I enable zones INIT, WARNING and ERROR in a release build and add FUNCTION, MEMORY and INFO to debug builds. Note that in a "ship" build (on Windows CE, WINCESHIP=1) debug/retail messages are defined as "nothing" (so all the logging code is effectively removed from the final binary).

If you define FULL_CONTEXT (line 98) the LOGMSG macro will output the full path to the source code filename in front of the message, instead of just the module name. We don't enable this by default because it makes the debug output cluttered and less readable (but it can be very handy in some cases).

This concludes the part of DebugZones.h that you should change. The remainder of the code mostly deals with the differences between Desktop Windows and Windows CE:

Note that the parameter to RETAIL/DEBUGREGISTERZONES MUST be NULL if you want to register debug zones from an application!

If you are using precompiled headers you have to set DebugZones.cpp to "Not Using Precompiled Headers" (in VS2008 right click DebugZones.cpp in your solution, click "Properties", then select "Precompiled Headers" under "Configuration Properties -> C/C++" and change the "Create/Use Precompiled Header" value). Now include "DebugZones.h" in any file you want to use debug zone logging.

The bigger problem is that all of the Silverlight applications shipped with WEC7 (video player, music player, photo viewer, etc) are shipped as pre-compiled executables and are not build on the spot. You will have to do a manual build of public\mediapps\oak\samples\cemp followed by a clean sysgen of your OS Design to get the photo viewer, video and music player to work again.

Of course these executables should have been recompiled and included in update 35. Note that I only identified the media player applications, but there are of course many more control panel items and executables that need to be updated. I hope a next update will update all of the Silverlight dependent pre-compiled files in the WINCE tree!

WARNING: You may be tempted to do a "Build and Sysgen" (blddemo without -q) to build the entire tree. Don't ever do this! It will leave your WINCE tree in a undetermined state. Read this to understand why. In fact you should remove the dangerous build commands from the Advanced Build menu. Read this to learn how.

Follow these steps:

Uninstall the SDK for your OS Design

Update your WEC7 tree with the latest updates

Open your OS Design

In the Solution Explorer, browse to \public\mediaapps\oak\samples\cemp

Right click cemp and choose "Rebuild (build -c)" from the context menu (do this for both a debug and retail build config!)

Now select the root of your OS Design in the Solution Explorer

And click "Clean Sysgen (blddemo clean -q)" from the Build->Advanced Build Commands menu (or Custom Build Commands menu if you followed these instructions)

Build the SDK for the OS Design (make sure you built the dependent build configuration first)

Close all Visual Studio instances

Install your new SDK

Recompile all of your Silverlight applications that were built against the previous SDK

Repeat step 5 for any other Silverlight components that do not work anymore after applying Update 35 (May 2014).

At GuruCE we work with a variety of boards from various customers. Some customers create their own boards from scratch, some use proprietary modules and yet some others choose a standard like Q7. We have found that standards, like Q7, work well for standard and well defined processor architectures like x86, but not so much for processor architectures that support a wide variety of functions even between different CPUs of the same family (like the Freescale iMX CPU range).

Martin Welford, CEO of our hardware partner Device Solutions has written a nice blog post about this and writes on the GuruCE blog as a guest writer:

Choosing a SOM – Why Standards don’t work for ARM modules

When choosing a System on Module (SoM) for a new project, you quickly find that there are some which follow a standard, and others which don’t. On the standards side, you may have heard of Q7 or SMARC. Proprietary modules use SO-DIMM connectors, board-to-board connectors or modules like our Topaz and Quartz products have no connector at all and solder directly to a board.

This post explores some of the reasons why we at Device Solutions have gone the proprietary non-standard path, and why we think standards don’t work for ARM and don’t deliver on the benefits you expect from a standard.

Why choose a standard?

For processor modules, having a second or third supply option sounds attractive. Obsolescence is a big problem and using a standard module to avoid this sounds like a compelling reason to go down that road. In fact it does work very well – for x86 based modules. However x86 chips are very well defined compared to the huge variation in features found on ARM based parts.

Why standards don’t work for ARM

ARM devices are used for a huge variety of applications, with an equally diverse set of requirements. If you have ever taken a close look at a Freescale i.MX part, you will see a lot of different functions and no single application makes use of them all.

This creates some big problems when trying to map an ARM chip to a standard interface. The challenges are:

Wide range of features, and not enough pins to expose them all.

Multiplexed features – which feature do you pick for a particular pin?

Functions change between chip generations and there may be no slot on the standard interface for a new feature. A good example of this is display interfaces – these have evolved from parallel TFT and chips have this interfaces along with LVDS, VGA or HDMI and now MIPI.

Designing with a standard ARM module

All this is not to say that ARM modules based on a standard don’t work at all. They do, but they might not do everything you expect (or need) them to do.
The first thing to check is, can you access all the features on the chip that you need? Make sure anything you think you might need is available. It is painful to get half-way through a design only to find you can’t get at a vital signal!

Using a standard module for second source reasons

This is where things get tricky and your design effort may effectively double. Because of all the reasons above, you can’t rely on two different standard ARM modules to give you exactly the same signals on the interface. It is important to identify what module you are going to use as a second source at the design stage. Every signal will need to be analysed and your base-board may need to have different build options for each module to get it working. Often this proves to be impossible because some vendors don’t share module schematics.

An alternative to second souring

Often the reason for having a second source is continuity of supply. Rather than invest in extra engineering (which is expensive and time consuming enough!), we suggest you ask the module vendor if they have an escrow service for their design files. This way should there be a problem for whatever reason, you will still have access to the module.

Conclusions

If you have made it this far, you will see that there are some issues with the current ARM based modules that follow a standard. Our advice is to choose a module that is the best fit for your design, and to solve second sourcing issues by other means.
There are a lot more details we haven’t gone into around this issue.

Congratulations! We are pleased to present you with the 2014 Microsoft® MVP Award! This award is given to exceptional technical community leaders who actively share their high quality, real world expertise with others. We appreciate your outstanding contributions in Windows Embedded technical communities during the past year.

If my memory serves me right, this is now the 13th award in a row! Very happy to be recognized in the field again!

Both Michel Verhagen and Erwin Zwart of GuruCE are Microsoft Embedded Most Valuable Professionals; a recognition of their expertise and community involvement in the field of Windows Embedded Compact.

The long awaited update for Windows Embedded Compact 2013 is now available for general download! The update now integrates Platform Builder and Application Builder with Visual Studio 2013. It also contains a (source) WiFi driver for the TI SDP44xx chipset, and a (source) BSP for the Freescale i.MX6 processor range.

GuruCE is proud to announce that Erwin Zwart, of our European branch, has been recognized by Microsoft for his technical excellence, community involvement and technical knowledge, and has received the Microsoft Most Valuable Professional (MVP) Award.

We believe our BSP for the Device Solution Opal iMX53 Module and Development kit is the best WEC7 BSP available for the Freescale iMX53 CPU. We have fixed many bugs in Freescale's stock code and added many new features, like for instance WIFI, full featured ECSPI drivers, GPIO drivers, etc.