Blog

Congatec Product Change Notification

iMX6
Congatec just released another PCN, telling customers they are updating their conga-QMX6 modules to the new hardware revision E.2. The changes are a different RTC chip (possibly, no details are given), different eMMC and a different Ethernet PHY.

The PCN states:

"Windows Embedded Compact (WEC7/WEC2013) and Android BSPs are not available for hardware revision E.2 and are therefore not supported."

But, GuruCE is happy to announce we of course still can support the new revision Congatec QMX6 for WEC7 and WEC2013 in our iMX6 BSP, also with these changes in hardware.

Contact us for more information.

The 'PBDbgPkg Package' did not load correctly

It's getting harder and harder to find answers when you encounter issues after installing Windows Embedded and its tools. The above error stumped me for a while, until I rediscovered that the Platform Builder Debug Package requires the Microsoft Visual C++ 2008 Redistributable package to work properly.

The link (including the later release SP1) can be found here.

Install both the x86 and the x64 versions and the error should disappear.

Windows Embedded Compact is NOT an RTOS... Again!

iMX6We just received a report from one of our customers that saw their high priority thread on WEC2013 not being scheduled for a long time, even though that thread was set to the highest priority in the entire system.

They saw behaviour very similar to what we described in this blog post. We investigated here by running our test code to show this bug on a tiny headless kernel with as little drivers included as possible and, to our grand surprise, it indeed showed the bug was back!

The customer was at Wave 5 update level. At GuruCE, we are always updated to the very latest (Wave 7 + March + June 2022) and we also saw the bug regression in WEC2013 (in WEC7 we fixed the issue ourselves at the time and that still worked). Microsoft fixed this bug in WEC2013 somewhere around November 2018 (see this blogpost), but apparently the bug regressed shortly thereafter through an update (Wave 5 or even earlier).

We have reported this issue again to Microsoft and in the mean time we have fixed this issue locally, now both for WEC7 and WEC2013, in our BSPs.

Customers of GuruCE can request this fix immediately through our normal support channels.

Anybody else that wants the fix for both WEC7 and WEC2013 can of course also contact us for support on this and other WEC related issues.

Bug image from Wikimedia Commons with reference to this meme

iMX6 ENET RCR PADEN sillicon bug

This is just a quick blog post to prevent anybody from having to spend days finding out why your Gbps connection on an iMX6 (or any iMX with a similar or same ENET/FEC module) stops working when stressing the network.

IEEE 802.11 requires all frames to be >= 64 bytes (or even >= 512 bytes on a Gbps network). If a small frame is received, the MAC can remove the padding bytes that make the frame up to 64 bytes. However, if a small frame has 0 data bytes, this can then result in an RxBD with the L and BDU bits NOT set (even though the attached buffer is bigger or equal than the maximum frame size).

If the bug happens, there is NO indication of an error. Nothing in EIR to indicate a problem and nothing in the Enhanced Buffer Descriptors either. Strangely enough, the RxBD's data length is always set to whatever you have set in MRBR[R_BUF_SIZE] and L and BDU are both 0. The ENET module can not recover from this situation. It really seems the uDMA has crashed and is not working properly anymore. Only a full reset of the ENET module allows it to work properly again.

Note that we ONLY see this issue when stress testing using Gigabit link speeds on active networks (where broadcast messages are flowing).

What we think happens is that small packets (usually broadcast packets) with a data size of 0 cause the ENET uDMA to crash if the PADEN bit (12) is set in RCR. This bit enables the MAC to remove padding bytes.

We know small packets are the culprit because stressing the network on an isolated network (witthout small broadcast packets) works perfectly fine. Also setting the BC_REJ bit (4) on a non-isolated active network works without problems (setting this bit results in the ENET MAC to reject all broadcast & multicast packets). Of course rejecting all broadcast and multicast packets is not a solution...

Workaround: DO NOT set bit 12 (PADEN) in RCR.

Error: failed PB timebomb check

iMX6
UPDATE 3 March 2022: Microsoft has finally fixed romimage (and several other issues) in the December 2021 Wave 7 update for WEC2013 that they released through DPC on the 15th of February 2022. Direct link to the download is here (but you need to have registered with DPC and have Embedded IoT access rights).

Today, 3 December 2021, Windows Embedded Compact 2013 decided enough is enough!

At least romimage.exe did...

According to Microsoft there should not be any time bomb checks in WEC2013. The last version to have time-bombs was WEC7, but today we find out this is not true. Note that this time-bomb happens for all WEC2013 installations, including the fully licensed ones.

New Zealand was the first to notice (hooray for me!), followed by Australia and by now I'm sure you on the other side of the world have found this blog post looking for a solution...

Well, here it is:

A bit of old-school hacking and cracking and here is the patched romimage.exe. A simple change of 'jg' to 'jmp' and we circumvent the time-bomb check.

Replace C:\WINCE800\public\common\oak\bin\i386\romimage.exe with the one in the 7z package you can download here.

Enjoy!

PS. 7-zip password is 'guruce'.

PS2. I have opened a support case with Microsoft to get this issue resolved via an official update but, since this is 100% blocking any work you do with WEC2013, I think/hope MS will not sue me for cracking their time-bomb while we wait for the official fix...

Bruce Eitman's Blog

In Feb 2021, Bruce Eitman's blog on GeeksWithBlogs.net went down with gwbs. It appears nobody was notified of gwbs going down, but luckily Bruce kept all his blog items backed up and all the articles have been accumulated and can be found in a PDF file at BlogAsBook.pdf on Bruce's OneDrive account.

Too good a resource to be lost!

Windows Embedded Compact / Windows CE Documentation problems - Part II

As you have undoubtedly noticed, the Windows Embedded Compact documentation search function is again completely broken.

For instance, if you search for "OpenStore" or even "OpenStore Compact 2013", you'd expect the OpenStore API would be the first search result. Unfortunately, that is not the case. This makes searching for CE API documentation extremely difficult.

We have asked, pleaded and begged Microsoft (for more than 6 months) to fix this, but unfortunately without result. We have now opened a support case to see if that would finally move Microsoft to fix the documentation for Windows Embedded Compact.

We still don't have a fix, but there is a workaround: place your "search-term + compact 2013" inside quotes in the search box, like this: "openstore compact 2013". If you need Compact 7 documentation, of course replace "compact 2013" with "compact 7".

That way, the search results will show the expected documentation link high up in the ranking.

WEC7 September 2020 update woes...

UPDATE May 11 2021:The asset on DPC has been fixed and is in the correct format now.

Here we go again... Update 77 (WEC7 September 2020) is again in the DDP (Disc Descriptor Protocol) format.

Follow the instructions from this blog post to get a working .img file again...

Apparently this is a common problem for many Microsoft updates for a myriad of product, not just the updates for CE... MS/DPC has been notified again.

17 consecutive years...

MVP award

WEC7 December 2019 update woes...

UPDATE:: On 26 March 2020, Microsoft uploaded a fixed version of the WEC7 December 2019 update to their DPC site. Direct link (you'll only be able to access this if you have an account with "Indirect Embedded / IoT OEM" permissions).

Somebody at the Microsoft update team uploaded the WEC7 December 2019 update in the wrong format. If you try to update using WEDU it will fail, and if you download the file from the Device Partner Center site you will see it is in the .zip file format (instead of the normal .img ISO format). Note that you need to register and request "Indirect Embedded / IoT OEM" permissions to see all Embedded updates on the DPC site.

If you unpack the X22-25842.zip file you get these files:


X22-25842.zip
    ├───Layer0
    │       CONTROL.DAT
    │       DDPID
    │       IMAGE.DAT
    │       MANIFEST.xml
    │
    └───Layer1
            CONTROL.DAT
            DDPID
            IMAGE.DAT
            MANIFEST.xml

That doesn't look like a normal update at all but in fact it is, just a little bit in disguise... It's in DDP (Disc Descriptor Protocol) format, a format used to describe a replication master. Looks like Microsoft just simply forgot to convert this into a normal .img ISO file.

The .img ISO file can be recreated by simply concatenating the two IMAGE.DAT files from the Layer0 and Layer1 folder. On a command prompt, type the following command:

copy /b Layer0\IMAGE.DAT+Layer1\IMAGE.DAT X22-25842.img

You can now mount the .img file as you normally do (we use the excellent Elorabytes Virtual CloneDrive freeware to easily mount .img files).

Now you can install the WEC7 December 2019 update. It should complete without any errors. If the concatenation didn't go well (or if you just mount the IMAGE.DAT file from the Layer0 folder) you will get errors like this:


Note that the WEC2013 December 2019 update is in the right (.img) format and can be installed as normal.

The issues have been reported to Microsoft, so hopefully it gets fixed soon.

GuruCE iMX6 BSP release 2391

iMX6
After many weeks of deep testing, GuruCE iMX6 BSP release 2391 is ready! This release adds some great new features, like High Assurance Boot and 100% flicker-free transition from bootloader splash to the CE desktop or your application, new drivers for displays, touch controllers, and RTCs, and many code improvements and fixes.

The release notes contain the full list of changes.

A picture is worth a million words, so imagine what a video can do...

For this release we have created a video showing how easy it is to work with our BSP and just how much functionality is included out-of-the-box:

Video table of contents

00:18 - SetWINCERoot
00:52 - BSP installation
01:12 - BSP structure
02:10 - OS Design Build Configurations
03:30 - BSP Catalog
06:30 - Change board and make catalog selections
07:58 - Board specific header file
09:28 - Reducing size of kernel image
11:27 - Processor specific catalog items
11:48 - Configuring hive-based registry and TexFAT
12:05 - Enabling & configuring High Assurance Boot
12:20 - Generating HAB certificates and keys
14:15 - Building the OS Design to generate HAB signed bootloader and kernel images
14:32 - Building a bootloader for the NXP Manufacturing Tool
15:00 - Configuring the NXP Manufacturing Tool
16:25 - Flashing the bootloader to SPI NOR Flash using Visual Studio
16:57 - Stopping Windows Mobile Device Connectivity services to allow download and debug over USB Serial
17:30 - Using CEWriter to flash bootloader, kernel and splash images to an SD card
18:58 - Configuring the bootloader
19:13 ---- Setting up the primary display
19:23 ---- Setting up the secondary display
19:29 ---- Setting up mirroring of the primary display on the secondary display
19:35 ---- Configuring Ethernet
19:48 - Checking HAB and burning fuses
21:31 - Booting to the CE desktop on a Nitrogen6X board
22:08 - Pocket CMD over UART (CLI, Command Line Interface)
22:15 - Included utilities
23:18 - CE Remote Desktop
23:52 - Switching between WEC7 and WEC2013
24:28 - Tiny OS Design (small headless configuration)
24:45 - Production Quality TEMPLATE driver, SDK and application code
25:50 - Configure the bootloader for download and KITL debug over USB Serial
26:56 - Setting breakpoints in driver source
27:12 - Preparing Visual Studio for driver debug and development
27:48 - Inspecting variable at runtime
28:18 - Unloading, modifying, rebuilding and loading drivers at runtime, without having to rebuild and download the entire kernel image

Our promise

We will keep improving our iMX6 BSP, adding new features and we will be supporting our customers for many years to come, long after the end of Microsoft's extended support end date of 10 October 2023.

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.

As always; if you want us to add some particular functionality, need any customization, driver or application development: contact us and we'll make it happen.

Don't forget to check our Testimonials page to see what some of our customers have to say about the GuruCE i.MX6 BSP.

Don't believe the hype? Try it yourself!

We've got free downloadable evaluation kernels for the Element14 RIoTboard, the Boundary Devices SABRE-Lite, Nitrogen6X and Nitrogen6_VM, the Device Solutions Opal6 (all variants), the Digi ConnectCore6, the NXP SDP (DualLite & Quad), the SDB-QP (QuadPlus), the NXP MCIMX6ULL EVK (ULL), the Toradex Colibri and the Variscite VAR-SOM_MX6 (Dual/Quad) Starter Kit.and more.

GuruCE website: https://guruce.com
iMX6 landing page: https://guruce.com/imx6
Latest iMX6 BSP release: https://guruce.com/imx6/latest

CE Platform Abstraction Layer (CEPAL) for Windows 10 IoT

Since Microsoft Windows Embedded Compact is now officially out of its support life-cycle, many of our customers are looking to see what they can replace CE with. The choice is often between Linux/Android and Windows 10 IoT.

The main problem when moving to a new OS is the, often massive, code-base that needs to be ported to the new OS. In the case of Linux/Android this is more of a complete rewrite than a port and this was no different for Windows 10 IoT Core, until Microsoft announced the CE Platform Abstraction Layer (CEPAL) for Windows 10 IoT:


Microsoft has provided platforms and operating systems for embedded devices for decades. As new offerings such as Windows 10 IoT have become available, our customers and partners are increasingly interested in the advanced security, platform, and cloud connectivity features that these OS provide. Customers moving from most earlier editions of Windows, like Windows XP and Windows 7, can do so with little effort because of binary compatible applications. Other operating systems, like Windows CE, require device builders to modify source code. Porting applications like this can be challenging.

To help these customers move to Windows 10 IoT and harness the full power of the intelligent edge including artificial intelligence and machine learning, Microsoft is developing technology that will allow most customers to run their existing, unmodified Windows CE applications on Windows 10 IoT while they continue to invest in updating their applications. You can learn more about how this technology works in the recent IoT Show episode Modernizing Windows CE Devices.

Source:https://microsoft-ce-pal.com

Microsoft is gauging how much interest there is for this feature, and based on that interest will assign resources and even add more functionality to Windows 10 IoT Core to make it even easier for CE applications to run on Windows 10 IoT Core.

So, if you are interested in moving your CE application to Windows 10 IoT Core, please let Microsoft know. The more people that fill out the form, the easier it will get to move to Windows 10 IoT Core.

Now that we can run CE application binaries on Windows 10 IoT Core, without the need to port or even recompile code, choosing between Linux/Android or Windows 10 IoT Core as your next OS becomes a no-brainer.

Of course the experts of GuruCE are ready to help you move to Windows 10 IoT Core; contact us for more information.

Watch the Channel9 video:

TLS 1.2 support and fix for RTOS bug released for WEC2013

Microsoft has published the Wave 4 October 2018 update for WEC2013. This update adds support for TLS 1.2 in WEC2013 (WEC7 already had support added for TLS 1.2 in an earlier update) and fixes the kernel handle table locking mechanism bug (as described in this blog post):

Kernel Handle Table Locking Mechanism Bugfix

181031_KB4466833 - Implemented Kernel Fast-Lock sync optimization for Windows Embedded Compact 2013.

Note that you have to set a FIXUPVAR to enable the fix. Add the following line to your config.bib file (MEMORY section) to include the fix for WEC2013:

kernel.dll:dwSyncFastLock 0 0x0001 FIXUPVAR

Unfortunately, the fix for this bug hasn't been released for WEC7. We're hoping Microsoft will publish an update containing the fix for WEC7 in the near future (the GuruCE i.MX6 BSP of course contains the fix for WEC7 as well).

Transport Layer Security

181031_KB4467918 - Transport Layer Security (TLS) 1.1 and TLS 1.2 support added to Windows Embedded Compact 2013.

TLS 1.1

The following subkey controls the use of TLS 1.1:

[HKEY_LOCAL_MACHINE\Comm\SecurityProviders\SCHANNEL\Protocols\TLS 1.1]

To disable the TLS 1.1 protocol, you must create the Enabled DWORD entry in the appropriate subkey, and then change the DWORD value to 0. To re-enable the protocol, change the DWORD value to 1. By default, this entry does not exist in the registry.

Note To enable and negotiate TLS 1.1, you must create the DisabledByDefault DWORD entry in the appropriate subkey (Client, Server), and then change the DWORD value to 0.

TLS 1.2

The following subkey controls the use of TLS 1.2:

[HKEY_LOCAL_MACHINE\Comm\SecurityProviders\SCHANNEL\Protocols\TLS 1.2]

To disable the TLS 1.2 protocol, you must create the Enabled DWORD entry in the appropriate subkey, and then change the DWORD value to 0. To re-enable the protocol, change the DWORD value to 1. By default, this entry does not exist in the registry.

Note To enable and negotiate TLS 1.2, you must create the DisabledByDefault DWORD entry in the appropriate subkey (Client, Server), and then change the DWORD value to 0.

Warning The DisabledByDefault value in the registry keys under the Protocols key does not take precedence over the grbitEnabledProtocols value that is defined in the SCHANNEL_CRED structure that contains the data for an Schannel credential.

Note: Per the Request for Comments (RFC), the design implementation does not allow SSL2 and TLS 1.2 to be enabled at the same time.

Download locations

If you have access to DPC (device partner center) with the right "Embedded" permissions then you can download the Wave 4 update for WEC2013 here: https://devicepartner.microsoft.com/en-us/assets/detail/x21-98917-img.

If you don't have access to DPC, get the Wave 4 update for WEC2013 here: https://www.microsoft.com/en-us/download/details.aspx?id=42027

Windows Embedded Compact / Windows CE Documentation

In their infinite wisdom, some team at Microsoft decided to move all the Windows Embedded Compact / Windows CE documentation to docs.microsoft.com. That's fine, but unfortunately they also decided this content is not allowed to be indexed by search engines anymore. The result is that searching for an API in Google or Bing does not return any link to the correct API documentation page anymore. We could live with that if the site itself would allow us to search, but unfortunately that functionality is broken now too. This makes finding Windows CE API documentation extremely difficult...

To make your life a bit easier, here are some links that should help you find what you are looking for a bit easier:

All CE documentation can be found here: https://docs.microsoft.com/en-us/previous-versions/windows/embedded/ee504814(v=winembedded.70)

Try to search for "CeSetThreadQuantum" using the search box on the top right to see that this functionality is broken now.
UPDATE: Microsoft has fixed the search functionality, hooray!

Without the search function working we have to manually click through the tree structure on the left to find what we need. Here are some handy links:

Kernel reference: https://docs.microsoft.com/en-us/previous-versions/windows/embedded/ee482973(v%3dwinembedded.80)

Kernel APIs: https://docs.microsoft.com/en-us/previous-versions/windows/embedded/ee482951(v%3dwinembedded.80)

Unfortunately, when you click on any API link on the above page, you will be redirected to the old Windows CE 6.0 documentation (and not to the expected WEC2013 documentation for the function you clicked).

To remedy this, manually change "winembedded.60" to "winembedded.80".

For example, clicking on the AllocPhysMem link will direct you here. Changing "60" to "80" will direct you to the expected page.
UPDATE: Microsoft has fixed the links to stay within the correct version, hooray!

Most other API documentation can be found here: https://docs.microsoft.com/en-us/previous-versions/windows/embedded/ee488372(v%3dwinembedded.80)

Use the tree on the left to find your function.

To find documentation for Windows CE 6.0, change "80" in the urls above to "60". To find docs for Windows Embedded Compact 7, change "80" to "70".

For some reason parts of the CE 5.0, CE.NET 4.2 and CE 3.0 documentation pages are still on MSDN and haven't been moved to docs.microsoft.com. Probably somebody forgot to move these... The result is that searching for just the API in Google or Bing returns links to the CE 3.0 documentation. Surely not the intended result by the team that made the decision to move all documentation to a new place on the Microsoft servers...

We've of course reported these issues to Microsoft. We'll update this blog post if the situation changes...

Windows Embedded Compact is NOT an RTOS!

Introduction

There’s a bad bug in the Windows Embedded Compact scheduler code on WEC7 and WEC2013 (and possibly earlier versions as well) that causes the OS to become non-deterministic. This means WEC7 and WEC2013 can NOT be called a Real-Time Operating System as long as this bug is present.

We have reported this bug to Microsoft, together with the fix, but unfortunately Microsoft has responded with:

“This would impact the kernel and the risks to taking this on far outweigh the good that would come of it so in the interest of not destabilizing the product we have opted to forgo fixing this issue at this time.”

The fix we provided has been thoroughly tested by us and has shown the kernel works absolutely fine with it in place. The fix is inside PRIVATE code so it is really Microsoft who would need to update this code and provide updated binaries, if only to prevent a maintenance nightmare.

The bug

The CE kernel keeps a table containing all handles. Access to this kernel table is controlled by a locking mechanism. If a thread requests a handle the kernel would need to alter the handle table (to add the handle). In this case, the thread requesting a handle becomes a “writer” of the handle table.

If a thread is merely requesting an existing handle from the handle table without any need to alter the handle table, the thread requesting the existing handle becomes a “reader”.

“Writers” to the handle table acquire an exclusive lock whereas “readers” just increase the lock count.

If a “reader” tries to increase the lock count but the handle table is already owned and exclusively locked by a “writer”, the “reader” blocks until the “writer” releases the exclusive lock. In this case priority inversion should occur, so that the lower priority “writer” thread gets scheduled and will release the exclusive lock as soon as possible so that the higher priority “reader” thread can continue as soon as possible.

Due to a bug in the CE kernel handle table locking code, this priority inversion sometimes does not occur resulting in high priority threads to have to wait until many lower priority threads run their thread quantum.

This absolutely and completely breaks the real-time scheduling mechanism of Windows Embedded Compact.

The code acquiring the handle table lock requires two steps:

  1. Acquire the lock
  2. Set the owner of the lock

The problem is that the Microsoft kernel code does not make this an atomic operation, meaning that a low priority “writer” thread can be pre-empted by a high priority “reader” thread in between step 1 and 2. The resulting situation of that pre-emption is that the handle table is locked, but the scheduler has no record of which thread owns the lock, and thus cannot apply priority inversion. The higher priority “reader” thread now has to wait for the lower priority “writer” thread to be scheduled at its original low priority. If there are any other threads active in the system at equal or higher priority than the priority of the “writer” thread, it means the high priority “reader” thread will have to wait for all these lower priority threads to run before it is allowed to continue.

It is important to note that the handle table contains ALL handles and the lock is a table-wide lock, meaning that ANY handle access can cause this situation. One thread can be using a file system handle, while another thread uses a completely unrelated device driver handle. There is no need for both threads to try to access the same handle.

The bug commonly shows itself in real-world scenarios, but so far hasn’t been diagnosed properly. The reason is that the bug is caused by a locking mechanism completely hidden from the user and it is therefore extremely difficult to find the root cause of this bug. Application code will look completely correct and connecting the issue with another, apparently completely unrelated, active thread in the system that together are causing this issue to arise, is extremely difficult.

The proof

We have created example code that quickly and reliably shows that this bug occurs on all systems running the WEC7 or WEC2013 OS. We have not tried CE6 yet, but it is very likely this bug exists in that version of the OS as well, and likely also in earlier versions of the OS.

The example code consists of a very simple stream interface device driver and a test application that creates:

  • One low priority “writer” thread that gets, uses and releases a handle to the 1st instance of the device driver in a tight loop without yielding (so no sleep). This thread runs at priority 255 (idle).
  • One low priority “busy” thread per core, simply executing a tight loop for 100 ms without yielding (so no sleep and no use of any handle). These threads run at priority 255 (so the “writer” thread gets scheduled in round-robin fashion together with these “busy” threads).
  • One high priority “reader” thread that uses a handle to the 2nd instance of the device driver in a loop, sleeping for 1 ms before using the thread handle again. This thread runs at priority 0 (hard real-time).

The “reader” and “writer” threads call a function inside the device driver instance that stalls (runs a tight loop without yielding) for 100 us.

The busy threads are there to make sure all cores are busy all the time and the low priority “writer” thread gets scheduled in round-robin fashion together with these busy threads.

The high priority “reader” thread will pre-empt all of these low priority threads every 1 ms.

The high priority thread tracks how long the DeviceIoControl call to the device driver takes, and breaks out if it detects the bug situation. Below is the output of the test run on a Nitrogen6X iMX6 Quad with only a single core active. We only activated a single core to show that many other threads can be scheduled in succession before our high priority thread can be scheduled again. This is explained in more detail later. It is important to note that the bug also occurs when enabling all 4 cores (and we have a busy thread on each core).


\> rttapp
Handle table lock mechanism bug test started at 12:06:10 on 2018/08/15
Low priority writer thread 1 started on processor 1
Low priority busy thread 1 started on processor 1
High priority reader thread 0 stall of 100 us took maximum 120 us.
Low priority busy thread 2 started on processor 1
High priority reader thread 0 stall of 100 us took maximum 149 us.
Low priority busy thread 3 started on processor 1
High priority reader thread 0 stall of 100 us took maximum 241 us.
Low priority busy thread 4 started on processor 1
High priority reader thread 0 stall of 100 us took maximum 242 us.
High priority reader thread 0 stall of 100 us took maximum 252 us.
High priority reader thread 0 stall of 100 us took maximum 253 us.
High priority reader thread 0 stall of 100 us took maximum 254 us.
High priority reader thread 0 stall of 100 us took maximum 306 us.
High priority reader thread 0 stall of 100 us took maximum 399156 us.
Could not copy OSCapture.clg to \Release, error 3
ERROR: High priority reader thread 0 stall of 100 us took 399156 us!
Handle table lock mechanism bug test ended at 12:07:18 on 2018/08/15
\>

It’s only a matter of time before the high priority “reader” thread pre-empts the low priority “writer” thread in between it acquiring the lock and setting itself as the owner of the lock. As you can see in the above example it took a little over a minute to show the bug, and the result is that our priority 0 real-time thread had to wait almost 400 ms before being scheduled again!

If the test application code detects the bug, it calls “OSCapture” with parameter “-c” so that OSCapture writes the CELog RAM buffer to a file in the root called “OSCapture.clg”. It will then try to copy this file to the \Release folder, which is only available in a KITL enabled kernel. We ran the above test on a Shipbuild kernel (so without KITL enabled), hence the copy to \Release failed. We used FTP to copy the OSCapture.clg file to our Shipbuild’s _FLATRELEASEDIR and opened the file from there with Kernel Tracker:

The above Kernel Tracker screenshot shows a “good” situation. As you can see, the low priority “writer” thread is running when it gets pre-empted by our high priority “reader” thread. In the good situation, the high priority “reader” thread tries to get the handle table lock, but the table is locked by the low priority “writer” thread and the owner thread is properly set. The kernel now inverts the priorities of the high priority “reader” thread and the low priority “writer” thread. Now the low priority “writer” thread runs at priority 0 and thus gets scheduled immediately so it can finish its work asap and release the handle table lock. As soon as it has released the handle table lock, the priorities are inverted again and our high priority “reader” gets the handle table lock and gets scheduled immediately. It now continues execution; real-time deterministic behaviour is guaranteed.

Theoretical total time it would take for the high priority “reader” thread to finish is:

(Execution time of high priority thread) + (Remaining execution time of low priority thread) + some overhead.

In a “bad” situation, the high priority “reader” thread preempts the low priority “writer” thread in between it getting the handle lock and setting itself as the owner of the lock:

The above Kernel Tracker screenshot shows a “bad” situation. As you can see, the low priority “writer” thread is running when it gets pre-empted by our high priority “reader” thread. In the bad situation, the pre-emption of the low priority “writer” thread happens in between it locking the table (step 1) and setting itself as the lock owner (step 2). Now the high priority “reader” thread wants to lock the handle table, but the table is locked by the low priority “writer” thread without the owner thread properly set. The kernel now has no idea which thread owns the lock and thus cannot invert priorities. The scheduler now simply schedules the next thread that is ready to run. This thread runs for an entire thread quantum as well as any other thread ready to run after that. In our case there are 4 busy threads that all run an entire thread quantum before our low priority “writer” thread gets scheduled again:

As soon as the low priority “writer” thread gets scheduled again, it resumes at step 2 and sets itself as owner of the handle table lock so now the scheduler knows which thread to invert the priority of. Immediately the low priority “writer” thread gets scheduled again so it can finish its work asap and release the lock. When that happens, the priorities are inverted again and our high priority “reader” thread can finally run, but only after having had to wait for all these other low priority threads to have run through their thread quantum.

As you can see; deterministic behaviour is completely broken and thus we cannot say Windows Embedded Compact is a real-time operating system with this bug in place.

Luckily, the kernel code containing the bug is available when you install the shared source. It is possible to clone, modify and build this kernel code so that locking the table and setting the owner becomes an atomic operation. With this fix in place, real-time deterministic behaviour is restored and Windows Embedded Compact can be labelled as an RTOS again.

Note: the GuruCE iMX6 BSP will include this fix in our upcoming release. Current customers can request this fix right away.

We are still hopeful Microsoft will change its opinion and release an update for WEC7 and WEC2013 to fix this issue. If that happens, we will update this article to reflect that.

The example code showing the kernel handle table locking bug and a pdf version of this article are available here.

UPDATE: Microsoft fixed this bug in WEC2013 (but unfortunately not in WEC7), see this blogpost.

Finally, the new GuruCE iMX6 BSP release is out!

iMX6
Let's call this the mystical release! It's taken much longer than planned to get this BSP release out due to a number of factors. Our last release was almost exactly 1.5 years ago, so what does 1.5 years of development bring?

Some highlights:

  • Support for UL & ULL
  • Display clone
  • CE Updater (update firmware from within CE)
  • Multi-touch
  • Super fast and reliable USB RNDIS and USB Serial for KITL
  • Simplified use of hive-based registry (no need to pre-format disks anymore)
  • Completely verified clock tree code
  • Gigabit Ethernet (on selected boards and with limitations due to NDIS)
  • Easy switch USB function
  • Copy/update firmware from SD to eMMC
  • Keep track of reason of last reset (power-on reset, software reset, watchdog reset, etc)
  • Many improvements to our BSP catalog to make working with our BSP even easier
  • And many more improvements, fixes and new features!

Further details in the release notes.

DVFS

We'd like to hear if you are interested in DVFS functionality (including full suspend-resume). Please contact us if you want this so we can gauge interest and prioritize this work accordingly.

TLS 1.2

Microsoft has recently added TLS 1.2 functionality to WEC7. When we asked Microsoft when this functionality would be added to WEC2013 the answer was that this was not planned at all. After a bit more push from our side, Microsoft is now willing to consider bringing TLS 1.2 also to WEC2013 and they have asked us to gauge interest and gather company names and contacts for them so they can justify the investment. Please contact us if you want TLS 1.2 on WEC2013 now or you think you may need it in the future.

UPDATE: Microsoft has now added support for TLS 1.2 to WEC2013, see this blogpost.

Our promise

We will keep improving our iMX6 BSP, adding new features and we will be supporting our customers for many years to come, at the very least until the end of Microsoft's extended support end date of 10 October 2023.

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.

Here's our wishlist:

  • Bring hardware accelerated H.264 video codecs to WEC2013 (not just WEC7)
  • Improve Gigabit network performance
  • Animated GIF bootsplash support
  • Create a solid solution for multi-display touch

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.

Don't forget to check our Testimonials page to see what some of our customers have to say about the GuruCE i.MX6 BSP.

Don't believe the hype? Try it yourself!

We've got free downloadable evaluation kernels for the Element14 RIoTboard, the Boundary Devices SABRE-Lite, Nitrogen6X and Nitrogen6_VM, the Device Solutions Opal6 (all variants), the Digi ConnectCore6, the NXP SDP (DualLite & Quad), the SDB-QP (QuadPlus), the NXP MCIMX6ULL EVK (ULL), the Toradex Colibri and the Variscite VAR-SOM_MX6 (Dual/Quad) Starter Kit.

GuruCE website: https://guruce.com
iMX6 landing page: https://guruce.com/imx6
Latest iMX6 BSP release: https://guruce.com/imx6/latest

Meltdown and Spectre on Windows CE / Embedded Compact

Meltdown
Spectre
Meltdown and Spectre have hit the world by storm and of course the Windows CE / Embedded Compact OS is also affected by these processor bugs.

See this ARM bulletin: https://developer.arm.com/support/security-update
And this PDF: https://developer.arm.com/support/security-update/download-the-whitepaper

At GuruCE we of course want to release patches to prevent malicious attacks through these attack vectors, but unfortunately the required code changes are all in places we do not have source code for or that we can't compile:

Variant 1 (Spectre) needs an update of the ARM compiler in CE/EC: https://developer.arm.com/support/security-update/compiler-support-for-mitigations
Variant 2 (Spectre) needs updates to the COREOS code (scheduler / vm code)
Variant 3 (Meltdown) does not apply to the Cortex-A9 (so does not apply to our iMX6 BSP)

We have therefore asked Microsoft for their plans on releasing patches for Windows CE/EC, and today (January 16, 2018) we received an answer:

"Since the desktop fixes were just released we are just beginning our investigation of the backports for CE7 and Compact 2013. Since CE6 and Handheld were based on XP it is unlikely that we will see a fix unless there is a fix released for XP desktop client."

Please note the above comment is not an "official Microsoft" statement. The comment was received by us in an email from a Microsoft support manager.

So, that is at least some good news. There are still a lot of devices around that run Windows CE 6.0, so in that respect not fixing that OS version is bad, but at least both WEC7 and WEC2013 are now being investigated to see what it takes to be patched by Microsoft.

No timeline yet, but we will keep pushing MS and keep you updated on progress.

The official information pages from Microsoft are here:

https://support.microsoft.com/en-us/help/4073757/protect-your-devices-against-spectre-meltdown
https://cloudblogs.microsoft.com/microsoftsecure/2018/01/09/understanding-the-performance-impact-of-spectre-and-meltdown-mitigations-on-windows-systems

There is no official info about Windows CE/EC on those pages yet, but hopefully CE/EC info will be added soon to the official pages, together with a timeline of when to expect the patches for CE/EC.

msvsmon.exe exceptions when debugging CE applications in VS explained

If you have ever done any application development for Windows Embedded Compact (aka "CE" or "WEC") devices then you no doubt have seen this ugly exception coming out of the serial port of the device:

Exception 'Raised Exception' (0x80010108): Thread-Id=050f001e(pth=ae493688), Proc-Id=044a001e(pprc=ae48a4a0) 'msvsmon.exe', VM-active=044a001e(pprc=ae48a4a0) 'msvsmon.exe'

It has been a long standing issue that so far nobody has really taken the time to investigate or explain, so let's change that!

Today I loaded up a WEC2013 debug kernel, started conmanclient and created a default "ConsoleApplication" targeting my device. I pressed F10 and waited for PB to break because of the exception. The callstack at the time of the exception is:

COREDLL!xxx_RaiseException(unsigned long 0x406d1388, unsigned long 0x00000000, unsigned long 0x00000004, const unsigned long * 0x009ffd48)  line 1347
VSDEBUGENG.IMPL!43e2da82()
KERNEL!APICall + 142 bytes
COREDLL!TlsSetValue(unsigned long 0x00000001, void * 0x00000001)  line 260 + 6 bytes
COREDLL!ThreadBaseFunc(unsigned long (void *) 0x00000000, void * 0x00000000)  line 1269 + 6 bytes

So, msvsmon.exe (VSDEBUGENG.IMPL) is actually raising the exception! But why?

Setting a breakpoint on the call to RaiseException allowed me to step in and see the arguments passed to RaiseException:

    dwExceptionCode     0x406d1388
    dwExceptionFlags    0x00000000
    nNumberOfArguments  0x00000004
-    lpArguments,4      0x009ffd48
    [0]    0x00001000
    [1]    0x43e8794c
    [2]    0x0526001a
    [3]    0x00000000

A quick google search on "Exception 0x406d1388" turned up this little gem of information: "How to: Set a Thread Name in Native Code".

So, what this RaiseException call actually does is simply setting the thread name by sending the VS debugger the event name through this exception. The reason it does this is so it is easier for you (the developer) to identify which thread you are debugging. This could be very useful when debugging multi-threaded applications; open the Threads window (CTRL-ALT-H) to see the thread names.

Knowing what we know now, we can see that the above 4 arguments are indeed matching what is listed on the MSDN page:

-    lpArguments,4      0x009ffd48
    [0]    0x00001000    dwType: Must be 0x1000.
    [1]    0x43e8794c    szName: Pointer to name (in user addr space).
    [2]    0x0526001a    dwThreadID: Thread ID (-1=caller thread).
    [3]    0x00000000    dwFlags: Reserved for future use, must be zero.

Long story short; I don't think there is any way to avoid this exception (even if MS would be interested in 'fixing' this). It's an annoyance, but not more than that. The exception can be safely ignored. It should not have any (or at least not have a big) impact on your debugging experience.

Visual Studio and Platform Builder problems on high DPI 4K displays

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!

[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers]
"C:\Program Files (x86)\Microsoft Visual Studio 9.0\Common7\IDE\devenv.exe"="~ DPIUNAWARE"
"C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv.exe"="~ DPIUNAWARE"

Thanks Doug!

Update: In Windows 11 the above trick doesn't work anymore. In Windows 11 you'll need to create/set this registry key:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\devenv.exe]
    "dpiAwareness"=REG_DWORD:0

Hosting webservices on Windows Embedded Compact gSOAP Part II (WEC2013)

Introduction

Back in 2011 I wrote an article about hosting webservices on Windows Embedded Compact with gSoap. I recently got some comments on this article and I am happy to notice that this subject is still relevant. The article written back in 2011 was targeted for Windows CE 6.0, and so I decided to redo the article for Windows Embedded Compact 7 (WEC7) and Windows Embedded Compact 2013 (WEC2013) including the latest version of gSOAP.

In fact for WEC7 you can just follow the original article as the environment (VS2008) has not changed. Due to an update of gSoap a modification is needed in order to make things work again. This modification, stubbing the time() function, is also needed for WEC2013 and therefore this article is mainly focused on WEC2013. A note is given in this article which part is relevant for WEC7.

The sample code provided has been build and tested with our iMX6 SDK, and the target used is the SABRE-Lite board. You can download the bootloader, the kernel (nk.bin or nklz4.bin) and the SDK for all of our supported platforms here.

You can find the source code attached to this article for both WEC7 and WEC2013. In order to use the attached source code you will need to install the GuruCE i.MX6 SDK and download the gSoap source code.

As said this article is based on the hosting webservices on Windows Embedded Compact with gSoap article and you can find the complete source listing in the original article. This article assumes that you at least have read the article

Windows Embedded Compact 2013

A lot has changed with WEC2013 and therefore I will discus the steps of how to (re)create the HelloWorldWebService application for WEC2013. The HelloWorldWebService application is a web service running on an Windows Embedded Compact 2013 device. We can reuse the desktop client application created in the previous article as long as the wsdl did not change. If the wsdl file has changed you need to open the desktop client solution and update the service reference in the solution explorer. This article assumes that the wsdl file has not changed and this thus means that you can use the desktop client application without any modification or rebuilding!

For this article we will use version 2.8.44 of gSoap which is the latest version at the time of writing this article. gSoap has been modified which causes the sample code, listed in the previous article, not to build anymore. We will explain how to fix the compile error in this article. With WEC2013 the development environment is Visual Studio 2012/2013/2015 which requires some modifications needed as well.

Create the native c++ gSoap webservice application for WEC2013

As a reminder; the steps to follow:

  1. Import the WSDL in a new project
  2. Let gSOAP generate a header file via wsdl2h.exe
  3. Let gSOAP generate the corresponding implementation *.cpp files via soapcpp2.exe
  4. Implement our methods

Step 1: Import the WSDL in new project

Open Visual Studio 2012/2013/2015 and create a new C++ smart device project (File | New | Project) and enter HelloWorldWebService as the name of the solution. In the "New Project" Dialog navigate to the Template "Templates | Visual c++ | Windows Embedded Compact | GuruCE iMX6 SDK" and select the "Win32 Console Application".

When you click OK the project is being created. There is no longer an option to select an empty project and thus you will get stuff for free here. This means we need to modify the project we just created, in order to reuse the same sources files which we used in the previous article. We also want to be able to use the same source files for WEC2013 and WEC7.

  1. First delete all source and header files which were automatically generated by Visual Studio's "new project wizard". e.g. right click on stdafx.h and choose remove | delete.
  2. Add the gSoap filters for the header and sources files (right click on header files and choose "Add | New Filter" and choose "gsoap" for the name of the filter.
  3. Create a new file called HelloWsdl.wsdl, copy the wsdl contents from here and import the file into the solution.

The layout of the solution should be looking like this:

Step 2: Let gSOAP generate the header file from our wsdl.

First download gSOAP in order to get the tools needed. You can download gSOAP from here.

Make sure you save the extracted files in an appropriate folder for you to remember because we need references to this folder within our visual studio project later on. I’ve put the gSOAP tools in the $(SolutionDir)

In the solution explorer in Visual Studio 2015 right click on the just imported wsdl file and select properties.

Select "All Configurations" for the configuration.

In the “Custom Build Tool“ pane, add the following command (make sure you get the path right and that the solution directory doesn't contain any spaces) in the “Command Line” section:

$(SolutionDir)gsoap-2.8\gsoap\bin\win32\wsdl2h.exe -s %(Filename).wsdl -o $(ProjectDir)%(Filename).h

!The macros in Visual Studio 2015 have changed compared to Visual Studio 2008!

This will run the wsdl2h.exe to generate our header file. The parameters specify the input and output file. In the “Outputs” field on the property page enter: $(FileName).h


Click “Apply” and “OK”, and then right click the wsdl file again and choose “Compile”.
Now our header (HelloWsdl.h) file is generated in the project directory, and we need to add this file to the project. In the solution explorer right click on the “gsoap” folder in the header section and choose “add existing item”. Navigate to HelloWsdl.h and add it.

Let’s do the same for generating the cpp file:

Step 2: Let gSOAP generate the cpp source file.

In the solution explorer right click on the HelloWsdl.h, that we just added in the previous step, and select “Properties”. In the “Custom build Tool“ add the following....wait, where is the "Custom Build Tool" configuration?

*** This is a BUG in Visual Studio 2015 ***

Press "Cancel" or "OK" to close the dialog. Yikes...The workaround is to manually edit the vxproj file (eg. with notepad) to add our custom build action. First save the solution!. After saving the solution edit HelloWorldWebService.vcxproj and look for the tag <ClInclude Include="HelloWsdl.h" />.

Replace:

<ItemGroup>
    <ClInclude Include="HelloWsdl.h" />
</ItemGroup>

Into

<ItemGroup>
    <CustomBuild Include="HelloWsdl.h">
      <Command Condition="'$(Configuration)|$(Platform)'=='Debug|GuruCE iMX6 SDK'">$(SolutionDir)gsoap-2.8\gsoap\bin\win32\soapcpp2.exe  -S $(MSBuildProjectDir)%(FileName).h</Command>
      <Outputs Condition="'$(Configuration)|$(Platform)'=='Debug|GuruCE iMX6 SDK'">$(FileName).cpp</Outputs>
      <Command Condition="'$(Configuration)|$(Platform)'=='Release|GuruCE iMX6 SDK'">$(SolutionDir)gsoap-2.8\gsoap\bin\win32\soapcpp2.exe  -S $(MSBuildProjectDir)%(FileName).h</Command>
      <Outputs Condition="'$(Configuration)|$(Platform)'=='Release|GuruCE iMX6 SDK'">$(FileName).cpp</Outputs>
    </CustomBuild>
  </ItemGroup>

Save the file and go back to Visual Studio. You will notice that Visual Studio detected that the project has been changed. Visual Studio will ask if you would like to reload the project and yes we do: Choose "Reload All":

In the solution explorer right click again on the HelloWsdl.h, and you will see that the "Custom Build Tool" step has been recovered:


Make sure that the paths are correct! You can see that we are using different macros than we used in Visual Studio 2008. Right click on the HelloWsdl.h file and choose "compile". This will generate a bunch of files as well, but we are not yet ready to build our solution.

Right click the gSOAP folder in the header section in your solution and add these header files:
- soapH.h
- soapStub.h

Right click the gSOAP folder in the source section in your solution and add these cpp files:
- soapC.cpp
- soapServer.cpp

The next step is to add stdsoap2.h and stdsoap2.cpp to your solution. You can find these two files in “gsoap-2.8\gsoap”. Add them together by right clicking the project in the solution explorer and select “Add existing item”. They will automatically appear under the correct “header” and “source” sections.

We’ve added the stdsoap2.h to our solution but we also need to add the directory where stdsoap2.h resides to the project's "include directory list". Add “$(SolutionDir)\gsoap-2.8\gsoap” to the include directory list by right clicking the project in the solution explorer and click "Properties". In the “Configuration Properties" | C/C++ | General” section you will find “Additional Include Directories”.

Now that we’re done generating files we can actually start to code!

Step 4: Implement our methods

Just like in the original article we need to create the source files HelloWsdl.cpp and HelloWsdlMethods.cpp to the solution. Copy or reuse the files HelloWsdl.cpp and HelloWsdlMethods.cpp used in the original article that you can find here! The content of those could be left unmodified!

Next step is to make sure that we configure the project not to use "Precompiled headers" because we deleted all those files in the beginning. We also want to be compatible with the WEC7 solution and thus we want to use the same source files. So right click on the solution explorer and navigate to the "Configuration Properties | C/C++ Properties | Precompiled headers". Choose "Not using Precompiled Headers "


For the same reason we need to add the UNICODE defines to the preprocessor definitions. Navigate to the "Configuration Properties | C/C++ Properties | Preprocessor". Add the UNICODE and _UNICODE definitions to "Preprocessor Definitions"


Now build the solution.... It will fail with the following compile error:

..\gsoap-2.8\gsoap\stdsoap2.cpp(16942): error C3861: 'time': identifier not found

This same compile error will occur when you follow the original article due to the fact that the gSoap sources are changed. For WEC7 you will only have to follow the following steps to make the solution working again

Now when you take a look at the specified line in stdsoap2.cpp the function time() is begin called which is not supported on Windows Embedded Compact. We need to stub/implement this method in Embedded Compact. This require two steps. The first step is to modify stdsoap2.cpp and tell that time() is external. Unfortunately this means that we need to modify the gSoap code and so whenever you update the gsoap package you will need to redo this step.

Open stdsoap2.cpp and add the following snippet just prior the function soap_rand_uuid where the time() function is used.

#ifdef WINCE
extern time_t time(time_t* timer);
#endif WINCE

The second step is to create the time() implementation. Add a new source code (cpp file) called "time.cpp"(right click on Source Files in the solution explorer and select: Add | New Item and choose c++ file(.cpp)). The time.cpp will hold the stubbed time function. You could proper implement the time() function, for example the OpenNETCF time replacement for CE can be found here, but as the method indicates that all it requires is a random uuid and for the sake of the simplicity of this article we will stub this function as follows:

#include <windows.h>

extern "C" time_t time(time_t* timer)
{
    return(time_t)rand();
}

Copy and paste the above code snippet in time.cpp and the complete project should look like:

As said the desktop client application should just work "AS-IS" as long as the wsdl hasn't changed.

That's it, build, deploy and enjoy!

Steps to follow to build the attached solution(s)

  1. Download the Webservice sample code and extract it somewhere suitable (In my case: H:\Data\development).
  2. Download and extract gSOAP into the $(SolutionDir) (So the gsoap-2.8 folder resides in H:\Data\Development\HelloWorldWebService).
  3. Open HelloWorldWebService7.sln or HelloWorldWebService8.sln depending on your environment.
  4. Modify stdsoap2.cpp to extern the time() function as described in this article.
  5. Build the solution.

Folder view:

GuruCE releases another major update of their i.MX6 BSP

iMX6
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.
  • And many more improvements, fixes and new features!

Further details in the release notes.

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.

Here's our wishlist:

  • Bring hardware accelerated H.264 video codecs to WEC2013 (not just WEC7)
  • Improve Gigabit network performance
  • Animated GIF bootsplash support
  • Create a solid solution for multi-display touch

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.

Don't forget to check our Testimonials page to see what some of our customers have to say about the GuruCE i.MX6 BSP.

Don't believe the hype? Try it yourself!

We've got free downloadable evaluation kernels for the Element14 RIoTboard, the Boundary Devices SABRE-Lite, Nitrogen6X and Nitrogen6_VM, the Device Solutions Opal6 (all variants), the Digi ConnectCore6, the Congatec Conga-QMX6, the NXP SDP (DualLite & Quad) and now also for the SDB-QP (QuadPlus), the Technologic Systems TS-4900 (Solo & Quad) and the Toradex Colibri.

GuruCE website: https://guruce.com
iMX6 landing page: https://guruce.com/imx6
Latest iMX6 BSP release: https://guruce.com/imx6/latest

Platform-specific macros in WEC2013 SDKs

As you can see in the WEC2013 release notes, the "Platform-specific Macro" in the SDK properties is no longer supported.
This is a change from WEC7 where you could simply add platform specific macros in the SDK's options dialog:

CE7 SDK options dialog

This way you can add custom preprocessor definitions that will be set by default for all your applications developed against your SDK. So, in the picture above, the preprocessor definition BSP_REV=9999 and __RPC_ARM32__ are set (on top of some definitions set by default). The impact of adding the above to the platform-specific macro option is that when you create a (new) smart device project against the SDK built with those platform specific macros set, the compiler options will look like this:

Test application compiler options

Adding these platform-specific macros can be very useful but unfortunately WEC2013 lost the ability to easily set these "platform specific macros". In WEC7 the platform-specific macros are stored in the SDK configuration file, but even adding the

<Property NAME="PlatformFamilyDefine">BSP_REV=9999;__RPC_ARM32__</Property>

tag to the SDK's configuration file (*.sdkcfg) doesn't work in WEC2013. Luckily, there is a possibility to achieve the same in WEC2013, but it is really unnecessarily complicated. We have no idea why Microsoft killed this SDK feature in WEC2013 and made it so difficult...

The build procedure for building an SDK is different for WEC2013 and WEC7. In WEC2013 the SDK preprocessor definitions are stored in a file named microsoft.cpp.sdk_name.ce800.props, located in:

<WINCEROOT>\public\COMMON\sdk\msbuild\[arch]\SDK_NAME\PlatformToolsets\CE800

[arch] is 'arm' or 'x86' depending on the SDK target architecture.

As you know, you should never modify any file in the PUBLIC (and PRIVATE) trees, but luckily this file is being copied during the sysgen phase and thus we can intercept and modify it before building the SDK.

To add custom pre-processor definitions to the WEC2013 SDK you need to modify the sysgenned and copied file microsoft.cpp.sdk_name.ce800.props in:

%SG_OUTPUT_ROOT%\misc\sdk\msbuild\[arch]\SDK_NAME\PlatformToolsets\CE800\microsoft.cpp.sdk_name.ce800.props

Here's a snippet from microsoft.cpp.sdk_name.ce800.props with our modifications:

<ItemDefinitionGroup>
    <ClCompile>
      <PreprocessorDefinitions>UNDER_CE;WINCE;_WIN32_WCE=0x800;ARM;_ARM_;_USESTL;BSP_REV=9999;__RPC_ARM32__;%(PreprocessorDefinitions)</PreprocessorDefinitions>
      <BasicRuntimeChecks></BasicRuntimeChecks>
      <SDLCheck></SDLCheck>
      <AdditionalOptions>/QRunaligned- %(AdditionalOptions)</AdditionalOptions>
    </ClCompile>
    <ResourceCompile>
      <PreprocessorDefinitions>UNDER_CE;WINCE;_WIN32_WCE=0x800;ARM;_ARM_;_USESTL;BSP_REV=9999;__RPC_ARM32__;%(PreprocessorDefinitions)</PreprocessorDefinitions>
    </ResourceCompile>
    <Midl>
      <PreprocessorDefinitions>UNDER_CE;WINCE;_WIN32_WCE=0x800;ARM;_ARM_;_USESTL;BSP_REV=9999;__RPC_ARM32__;%(PreprocessorDefinitions)</PreprocessorDefinitions>
    </Midl>
  </ItemDefinitionGroup>

As you can see in the above xml, we've added BSP_REV=9999 and __RPC_ARM32__ to the PreprocessorDefinitions tag.

After this modification you can build your SDK so it will contain the custom preprocessor definitions.

To automate this process you could, for example, create a batch script that will run after the make image phase (post-makeimage). This batch script could replace or modify the microsoft.cpp.sdk_name.ce800.props file. Getting a batch file to run after the make-image phase is easily done through the project properties:

Post-MakgeImage build step

Check out this blog post for ideas on how to create a useful batch file to add, replace or remove strings from arbitrary (text) files.

Using STL (C++) in Platform Builder subprojects

Sometimes it is nice or necessary to be able to use STL or other C++ features in Platform Builder subprojects. This blog post explains what you need to do to make this work:

In your subprojects sources file, add the following path to _ISVINCPATH:

$(_WINCEROOT)\public\common\sdk\crt\include\stl;

And add the following lines to TARGETLIBS:

    $(SG_OUTPUT_ROOT)\sdk\crt\lib\ARM\libcpmt.lib  \
    $(SG_OUTPUT_ROOT)\sdk\crt\lib\ARM\msvcrt.lib  \

You can use libcpmtd.lib and msvcrtd.lib for debug builds.

And finally add:

CDEFINES=/EHsc

The required libraries are documented here.

After the above changes, the subprojects build the same as standalone SDK projects.

Thanks to Rajiv for figuring this out!

GuruCE releases feature update of their i.MX6 BSP

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

Some highlights:

  • Updated Vivante GPU driver to v5.0.11.p8.3
  • Multi-monitor functionality now working properly for all resolutions on i.MX6 Solo and DualLite processors.
  • Boot splash images can now be stored in the system partition (next to the bootloader and kernel images). No need to have a FAT12/16/32 formatted partition anymore.
  • Background color of boot splash screen now determined by color of bottom right pixel of the boot splash image.
  • Updated CEWriter tool to support flashing boot splash images.
  • Added support for external drives (like SATA connected through USB) to CEWriter.
  • Fixed flickering mouse cursor and bad performance when drawing under the mouse cursor.
  • OpenGL XAML render plugin now working properly.
  • Added support for NAND to bootloader and kernel.
  • Added support for external RTCs (Real Time Clock chips). Currently supported (and runtime auto-detected) chips are ISL1208, ISL2020, M41T0, M41T8x and RV4162.
  • Added PCIe core reset code so PCIe driver works on DualPlus/QuadPlus
  • 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).
  • Added bootshell option for directing clocks to CKO1/2 pads
  • Improved clocking code to now properly control reference counts of static divider root clocks
  • Moved clocking code to more logical place in the BSP tree.
  • Further cleaned up and refactor of large parts of the interrupt code.
  • Further clean-up and re-structure of BSP code and tree.
  • And many more improvements, fixes and new features!

Further details in the release notes.

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)
  • Bring hardware accelerated H.264 video codecs to WEC2013 (not just WEC7)
  • Improve Gigabit network performance
  • Animated GIF bootsplash support
  • Create a solid solution for multi-display touch

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.

Don't believe the hype? Try it yourself!

We've got free downloadable evaluation kernels for the Element14 RIoTboard, the Boundary Devices SABRE-Lite, Nitrogen6X and Nitrogen6_VM, the Device Solutions Opal6 (DualLite & Quad), the Digi ConnectCore6, the Congatec Conga-QMX6, the NXP SDP (DualLite & Quad) and now also for the Technologic Systems TS-4900 (Solo & Quad) and the Toradex Colibri.

GuruCE website: https://guruce.com
iMX6 landing page: https://guruce.com/imx6
Latest iMX6 BSP release: https://guruce.com/imx6/latest

Adding (all) locales to your Windows Embedded Compact 7 OS

Introduction

This article explains how you can add all of the locales to your OS. You can find a brief description on the National/Regional Language Support (NLS) Catalog Items and Sysgen Variables page.

Although everything in this article relates to Windows Embedded Compact 7 (WEC7), the same is applicable to Windows Embedded Compact 2013 (WEC2013/CE8).

When I was porting a BSP and OSDesign from Windows CE 6.0 to Windows Embedded Compact 7, I ran into some issues regarding localization that I would like to share with you today.

Upgrading your OS from Windows CE 6.0 to Windows Embedded Compact 7

When you are in the process of upgrading or porting Windows CE 6.0 to Windows Embedded Compact 7 or Windows Embedded Compact 2013, you might face some hurdles to get it all working. Once you manage to overcome all hurdles and the operation system is running you're almost done. All you need to do now is adding some missing locales to the OSDesign. That can't be that hard, can it?

Well...

In the good old days of Windows CE 6.0 this was easy. You just had to select the locales you wanted to support in your OS in the properties page of your OSDesign. Simply right click on your OSDesign in the solution explorer, select properties and navigate to the locale tab. That tab page allows you to select the locales you want to support in your OS, then do a rebuild, and that's it.

Windows CE6 Locale Properties

Unfortunately, with Windows CE 7 this is all not so easy anymore. I have no idea why on earth this functionality was 'streamlined', but there are more decisions made around Windows CE that escape any sane reasoning I guess....

To get it all to work in Windows Embedded Compact 7 or 2013 you need to perform some extra steps, and that's exactly what this blogpost will explain. I'll also show you that it is not possible to add ALL, seemingly supported, locales to your OSDesign. To all those people living in Friesland (part of The Netherlands) that speak Frisian or those from Inuktitut (Canada) that use syllabics and some others; sorry, you're out of luck when it comes to Windows Embedded Compact!

In short you need to:

  • Add SYSGEN_NLS_XXX variables to the OSDesign
  • Manually add locales to nlscfg.inf to include all the locales needed for the .NET CF

To show what locales the OS running on your device supports, I created a little test program that enumerates over the available locales and will try to set the culture info and compare information associated with the locale. When you run the application you will see, unless you configured a different default locale, that only one locale "English (United States)" is listed. When you try to use a locale not supported by the OS, for example CultureInfo.CreateCulture("nl"), a PlatformNotSupportedException will be thrown by the managed application. This is reasonable because the locale was not supported in the first place.

The LocaleInfo test program looks like:

List<CultureInfo> missingLocale = new List<CultureInfo>();
List<CultureInfo> supportedLocale = new List<CultureInfo>();
foreach (CultureInfo ci in CultureInfoHelper.GetCultures())
{
    try
    {
        CultureInfo cultureInfo = CultureInfo.CreateSpecificCulture(ci.Name);
        CompareInfo compareInfo = cultureInfo.CompareInfo;
        supportedLocale.Add(ci);
    }
    catch (PlatformNotSupportedException)
    {
        missingLocale.Add(ci);
    }
}

// print out LCID
StringBuilder localeInfo = new StringBuilder();
foreach (CultureInfo locale in missingLocale)
{
    localeInfo.Append(locale.LCID.ToString("X4") + " ");
}

As you can see, the program enumerates the available locales and the Language Identifier (LCID) is stored (and printed), which we will use later. The test application (LocaleInfo.zip) is attached to this blogpost (in full source code). The test application will create a file (locale_info.txt) containing the locale information for the OS it is running on.

Here's what we need to do to add locale support to your OS:

Selecting the right SYSGEN_NLS_XXX variables

The easiest way to add components (sysgen variables) to your OS is to select the sysgen variables in the Catalog: open your OSDesign and locate the catalog window. Navigate to "International" and select the country of the locale you want to add. Let's take Africa as example. Expand "Afrikaans", just like in the screenshot below. Now if you want to add the locale "Afrikaans", make sure you select both variables, otherwise it will not work. So; add SYSGEN_NLS_AF and SYSGEN_NLS_AF_ZA. Note that in order to support one single language you need to select two sysgen variables!

Windows Embedded Compact 7 Locale Sysgen Variables

If you only want to support a few locales than going through the list and manually selecting the locales is not such a big problem. Just make sure that you select both variables per language/locale. Again an example; for the dutch language you'd need both SYSGEN_NLS_NL and SYSGEN_NLS_NL_NL.

In total, there are 197 locales available and if you want to add all those locales you will most likely end up with some form of RSI (Repetitive Strain Injury). To prevent this I created a little batch file that will set all locales that are supported in the catalog. I simply took the list of supported locales from <WINCEROOT>\public\CEBase\oak\misc\winceos.bat. If you're interested in that batch file please contact me and I'll send it to you.

Now that you have selected the locales you want and thus added sysgen variabls, you need to do a rebuild of the OS, so click Rebuild Solution (to understand what to build when read this blogpost).

If you select all available locales, rebuild the entire solution and run the test program again you will see, by examining locale_info.txt, that the application still detects unsupported locales. How is this possible? You've just added them all, didn't you?

Mysteries.. Apparently we need to add the missing locales manually to the OS:

Add locales to nlscfg.inf to support all locales needed for the .NET CF

Apparently adding the sysgen variables is not enough for some locales so we need to do a bit more, but first a little background information:

The .NET Compact framework depends on a 'list' of locales and this list is called the NLS Table. The NLS table describes the locale identifiers (LCIDs) available in your OS. For more information about the NLS Table and the nlscfg.inf, read this page on MSDN: Configuring the NLS Table. In short; the nlscfg.inf contains a list of LCIDs which should be in sync with the locales you enabled via the NLS sysgen variables. You can find the default nlscfg.inf in <WINCEROOT>\public\COMMON\oak\files.

When you run the test application LocaleInfo.exe, it will create a file containing locale information. A snippet from this generated locale_info.txt file:

Locale information current device
Missing locale LCIDs
------------------------------------------------
045E 3801 3C01 1401 0C01 0801 2C01 3401 3001 1001 1801 2001 4001 0401 2801 1C01
2401 047A 044D 082C 042C 046D 0423 0402 0845 0445 0451 047E 141A 0483 0405 0452
0465 0408 540A 0425 0429 0464 0462 083C 0484 0447 0468 040D 0439 101A 041A 042E
040E 042B 0470 0478 045D 0411 0437 043F 046F 0453 044B 0412 0457 0440 046E 0454
0427 0426 0481 042F 044C 0450 0850 047C 044E 043A 0461 046C 0482 0448 0446 0415
048C 0463 0486 046B 086B 0C6B 0417 0418 0419 0487 044F 0485 043B 045B 041B 0424
041C 1C1A 0C1A 301A 281A 181A 081A 2C1A 045A 0449 044A 0428 041E 0442 0432 041F
0444 085F 0480 0422 0420 0843 0443 042A 0488 0434 046A 0804 0C04 1404 1004 0404
0435
------------------------------------------------

The next step is to clone nlscfg.inf located in <WINCEROOT>\public\COMMON\oak\files to <WINCEROOT>\PLATFORM\<YOURBSP>\FILES and then add the list of missing LCIDs listed in locale_info.txt. The contents of the <WINCEROOT>\PLATFORM\<YOURBSP>\FILES folder are copied during the buildrel build phase and after that the makeimg phase will process and include all the locales listed in nlscfg.inf. If you click "Copy files to release directory" followed by a "Make Image", you will see that the makeimg build phase will exit with an error. The makeimg process will fail with error "The cenlscmp tool has exited with error code 1". If you examine the <WINCEROOT>\build.log, it will provide you with some additional information:

CeNlsCmp: Did not find locale 047a in locale file
error MSB3073: The command "cenlscmp <WINCEROOT>\<OSDesign>\..\RelDir\Shipbuild\postproc\nlssrc.txt
<WINCEROOT>\<OSDesign>\..\RelDir\Shipbuild\nlscfg.out
<WINCEROOT>\<OSDesign>\..\RelDir\Shipbuild\wince.nls
<WINCEROOT>\<OSDesign>\..\RelDir\Shipbuild\nlscpg.txt" exited with code 1.

The first line "CeNlsCmp: Did not find locale 047a in locale file" informs you that apparently information is missing for LCID 047a somewhere. I have unfortunately not been able to track down the missing information, so either there is still something missing or there is a bug in the tooling.

I have gone through the process of removing all LCIDs that cause the cenlscmp to break and provide you with a list of all 'supported locales' that can be enabled, just in case you want it 'all'. Attached to this blogpost you'll find the zipped nlscfg.inf file.

In the locale_info.txt (also attached to this blogpost), you'll find a summary of supported and non-supported locales:

Supported Locale

Total locales installed:197
Total locales supported:146
Total locales not supported:51

I hope that this information will save someone somewhere some time! ;-)

QT 5.6.0 official release on the GuruCE iMX6 BSP

Official release Qt 5.6.0 builds and works fine with our GuruCE iMX6 BSP and SDKs!

Download Qt 5.6.0 official source here: https://download.qt.io/official_releases/qt/5.6/5.6.0/single/

We still need to make three patches: download the patches.

The complete guide to building Qt to work with the GuruCE iMX6 BSP and SDK can still be found here: https://guruce.com/blogpost/wec2013-and-qt.

There are no changes in the build steps apart from using the links above for Qt source and the required patches.

GuruCE releases major new version of their iMX6 BSP

iMX6
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.

Some highlights:

  • Added true multi-monitor support: extended desktop with GDI, OpenGL-ES & OpenVG on all active displays
  • Added support for multi-display boot splash screens, with virtually flicker-free transition to the Windows Embedded Compact desktop
  • Multi-display configuration can be dynamically configured in the bootloader with immediate activation of (and display of bootsplash on) the selected displays
  • Latest Vivante GPU driver (5.0.11.p8.0 + 2G)
  • Introducing CEWriter; a Windows utility that can write a bootsplash, bootloader & kernel image directly to a SATA drive or SD card from your PC
  • Added support for iMX6 Dual+ and Quad+ processors
  • Added support for PCIe enumeration over bridges and switches
  • Added support for Command Line Interface (cmd.exe) over UART
  • Added support for VMINI network adapter while debugging over KITL
  • Added support for very large SATA disks
  • Added support for SD/eMMC 8-bit mode
  • Added support for eMMC 4.4 DDR mode
  • Added support for the Technologic Systems TS-4900 Solo & Quad board
  • Added support for the Device Solutions Opal6 Quad board
  • Added support for the Toradex Colibri DualLite board
  • And many more improvements, fixes and new features!

Further details in the release notes.

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

Here's our wishlist:

  • Allow storing bootsplash image in system partition (instead of file partition as it is now)
  • Support bootsplash image to be stored in exFAT formatted file partitions
  • Animated GIF bootsplash support
  • Bring hardware accelerated H.264 video codecs to WEC2013 (not just WEC7)
  • Improve Gigabit network performance
  • Create a solid solution for multi-display touch
  • 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.

Don't believe the hype? Try it yourself!

We've got free downloadable evaluation kernels for the Element14 RIoTboard, the Boundary Devices SABRE-Lite, Nitrogen6X and Nitrogen6_VM, the Device Solutions Opal6, the Digi ConnectCore6, the Congatec Conga-QMX6, the Freescale/NXP SDP and now also for the Technologic Systems TS-4900 and the Toradex Colibri.

GuruCE website: https://guruce.com
iMX6 landing page: https://guruce.com/imx6
Latest iMX6 BSP release: https://guruce.com/imx6/latest

Meet us at the NXP FTF 2016 TECHNOLOGY FORUM from 16 to 19 May 2016, in Austin, Texas.

QT 5.6.0 Beta release is out!

Recently QT 5.6.0 Beta has been released. You can download the QT5.6.0 beta package from the QT download page.

So for anyone who followed the tutorial how to build QT for WEC2013 with the GuruCE iMX6 SDK, a new patch is available for download.

There are no changes in the build steps you only need to use the beta patch to run!

WEC2013 and Qt

Introduction

On a regular basis we receive requests whether it is possible to run Qt applications on platforms running our iMX6 BSP. To be able to run Qt applications you need a "Qt Application SDK" which is build against our GuruCE iMX6 SDK. This article will show you how to build the Qt Application SDK so you can run Qt applications on a device running the GuruCE iMX6 BSP.

This step described in this text apply to the QT5.6 alpha release which (sort of) includes WEC2013 support in combination with Visual Studio 2013. The WEC2013 support in this version of Qt is not completely working yet so you'll need to perform some additional steps to make it all work.

We'll show you exactly what you need to do, and while we're at it we'll add support for Visual Studio 2015 as well!

This article seems quite big but actually it isn't all that hard. For the impatient; you'll find a quick reference guide of all the steps to follow at the end of this article.

Qt 5.6 Alpha Release

The instructions in this article apply to the Qt 5.6 alpha release. As soon as we have tested the official 5.6 release, and perhaps other future releases, we'll update this article so it all works with the latest Qt release.

Qt is an open-source project and the git repositories allow you to get the latest and, sometimes not so, greatest developer branches. You can find instructions for getting the complete source code tree from the git repository here. Qt is a very active project, which is good in a way, but it also means there are a lot of commits every day. This can easily result in a broken build, especially since not every commit is checked against all the different platforms and build environments (which make sense in a way). Our suggested approach is to pick the latest stable release and make that work. Of course you can take the latest alpha, beta or even developer branch but in that case you may want to prepare yourself for some long days/nights chasing build errors! ;-)

[Update 21/12/2015]
QT 5.6.0 Beta is released. You can find the patch needed in order to build QT5.6.0 beta here. There are no other changes required in order to build QT for WEC2013 just as described in this article, except that you need to run the beta patch.

Qt Prerequisites

You'll need to download and install a couple tools and packages before you can start building the Qt application SDK:

  • Download and install Python. Make sure the Python binary folder is added to the system's %PATH% variable. This will be requested during installation.
  • Download and install Perl. Also the Perl binaries must be accessible by the build system, and so the binary folder also needs to be added to the %PATH% system variable.
  • Install Visual Studio 2013 or Visual Studio 2015.
  • Install Application builder for Embedded Compact 2013".
  • Download and install the latest GuruCE iMX6 SDK. You can pick any preferred platform. For Visual Studio 2015 you'll need the SDK of a release later than r550 (coming soon).
  • Download the Qt 5.6 alpha release from this location. Extract the source to any folder but make sure the extracted source code is on the same drive as the "working directory" (the directory where your generated binaries will end up).

The Qt 5.6 alpha source path used in this article is: H:\qt-everywhere-opensource-src-5.6.0-alpha
The Qt working directory used in this article is: H:\Qt\QT5.6a

Patch the Qt sources

The current 5.6 alpha release won't build for Windows Embedded Compact without some changes to the Qt source tree. We have packaged up all required patches and made them available for download here). All these patches are made by us and may not conform to the Qt coding standards, so please monitor the bug tracker for Qt to see if better solutions become available.

One of the patches also results in some mkspec files to be copied into the "Qt source tree\qtbase\mkspec" folder. These mkspec's contain the configuration information for the development environment and target platform. In our case we need mkspec files to indicate we use Visual Studio 2013 or Visual Studio 2015, the GuruCE iMX6 SDK and a Windows Development machine.

All said and done, lets build a Qt Application SDK now!

Building the Qt Application SDK

1. Install the patches

Download the Qt56alpha_patches.zip file and extract it in the root of the QT5.6a source path. You should end up with a "patch" folder after extraction (e.g. H:\qt-everywhere-opensource-src-5.6.0-alpha\patch). Navigate to this patch folder and run the patch.bat batch file.

If you want to undo the patches just open a Command Prompt in the patch folder and run:

H:\qt-everywhere-opensource-src-5.6.0-alpha\patch>patch -u

This will revert the changes made by our patches and restore the original Qt code tree.

2. Open Visual Studio 2013 or Visual Studio 2015 Developer Command Prompt

With Visual Studio 2013 there is no 'standard' start menu item for opening the Visual Studio 2013 "Developer command prompt", but shortcuts are available. Open a file explorer and navigate to the Shortcuts folder inside your Visual Studio installation folder, eg:

"C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\Tools\Shortcuts"

Run the shortcut: "Developer Command Prompt for VS2013"

For Visual Studio 2015 there is a start menu item for the Developer Command prompt, just type "Command" in the desktop search pane and it should show up:

In both cases (VS2013 or VS2015) you can drag the developer command prompt shortcut to the desktop. This allows you to quickly open a developer command prompt whenever needed.

3. Set %PATH% variable to the source path

In the Visual Studio 2013/2015 developers command prompt, navigate to your Qt working directory (e.g. H:\Qt\QT5.6a). Remember that QT5.6a source path and the work directory must be on the same drive. Add the QT5.6a source path to the %PATH% environment variable by executing the following command (of course change the drive and folder name if needed):

set PATH=%PATH%;H:\qt-everywhere-opensource-src-5.6.0-alpha

You can also add this variable to the system environment variables. In that case you must not forget to change it in case you change the Qt working folder (for instance when you want to build a Qt Application SDK against a different Qt source tree). Setting the Qt source path in the command prompt is the most flexible way and allows you to build a Qt SDK against different Qt source trees.

4. Configure the Qt build environment

Execute the following command in the Visual Studio 2013 Developer command prompt (followed by enter):

H:\Qt\QT5.6a>configure -platform win32-msvc2013 -xplatform wince80GuruCE-armv7-msvc2013 -rtti -mp -ltcg -release -opensource -confirm-license -no-compile-examples -nomake tests -opengl es2 -openvg -skip qtandroidextras -skip qtactiveqt -skip qtsensors -prefix %CD%\SDK

Or for Visual Studio 2015 execute the following:

H:\Qt\QT5.6a>configure -platform win32-msvc2015 -xplatform wince80GuruCE-armv7-msvc2015 -rtti -mp -ltcg -release -opensource -confirm-license -no-compile-examples -nomake tests -opengl es2 -openvg -skip qtandroidextras -skip qtactiveqt -skip qtsensors -prefix %CD%\SDK

Now relax, take a deep breath and we'll go over the parameters while configure.bat runs (shouldn't take more than a minute or so).

The configure tool will generate the configuration and build tools needed to build Qt for the given platform and environment. Check the Qt documentation for detailed information regarding the configure tool.

    -plaform win32-msvc2013 -or- win32-msvc2015: Specifies Windows Desktop and Visual Studio version.
    -xplatform The target platform: the GuruCE iMX6 SDK.
    -rtti Compile run-time type information.
    -mp Enable multi-processors when building the SDK.
    -ltcg Use link-time code generation.
    -release Build a release configuration for the SDK.
    -opensource Compile and link the open source edition of Qt Check Qt licensing for more info.
    -confirm-license By specifying this parameter you automatically accept the selected Qt license (in our case this is the open-source license).
    -nomake Exclude a specific part from the build. In our case we skip building the tests. In case you want to save some disk space you can specify -nomake examples. This will leave out the Qt examples. In our case we want to use the examples later on so don't specify -nomake examples.
    -no-compile-examples Indicates not to compile the examples but include them as source in the SDK.
    -opengl The GuruCE iMX6 BSP fully supports hardware accelerated OpenGL ES2.0, so enable es20 in Qt.
    -openvg The GuruCE iMX6 BSP fully supports hardware accelerated OpenVG, so enable OpenVG in Qt.
    -skip This will exclude complete modules from the build. In our case we skip the qtandroidextras, qtactiveqt and qtsensors modules.
    -prefix This indicates the path of where to install the SDK locally. If you don't specify the -prefix parameter, everything will be installed in the working directory.

When configure.bat is finished you can review the used configuration settings by checking the "config.summary" file, which is located in the generated qtbase folder (in our case H:\Qt\QT5.6a\qtbase).

5. Build the Qt Application SDK; time for coffee!

To start the build process the only thing left to do is to enter the following command in the Visual Studio 2013/2015 Developer command prompt:

H:\Qt\QT5.6a>nmake

This process will take roughly an hour depending on your development machine configuration.

Install the SDK

When the build is done we can generate the Qt Application SDK installer. Type the following command followed by enter:

H:\Qt\QT5.6a>nmake install

This will generate the folder specified by the -prefix in the configure command line, in our case H:\Qt\QT5.6a\SDK.

The last thing we need to do is copy a qt.conf file into the SDK's bin folder. qt.conf is used to override hard-coded paths defined in the Qt libraries. The qt.conf file specifies where a Qt application can find libraries to link against. Every application needs a seperate qt.conf file if it's not present in the SDK\bin folder.

The contents of the qt.conf are quite simple:

[Paths]
Prefix=..

Download and extract the qt.conf.zip file and copy the qt.conf file to the generated SDK\bin folder (e.g. H:\Qt\QT5.6a\SDK\bin).

That's it! Now you can copy the SDK folder to the device. The size of the Qt Application SDK is approximately 420MB so this Qt Application SDK can be easily shared among developers.

Test Qt

When the Qt Application SDK is built, installed and it contains the qt.conf file in the SDK\bin directory, we can copy the Qt Application SDK to the device and run a Qt application:

  • Copy the SDK folder to the Windows Embedded Compact device.
    You can copy the SDK folder to the root of an SD card and insert the SD card into the device running CE. The Qt Application SDK folder contains an "examples" folder with sample applications you can try. To run the sample applications continue the steps below.
  • Telnet to the device.
  • Navigate to the Qt Application SDK bin folder: cd \SD\SDK\bin.
  • Start qml.exe with the following parameters, followed by ENTER:
\SD\SDK\bin>qml ..\examples\quick\animation\animation.qml

Telnet Screenshot

  • Choose any of the samples, for example "ColorAnimation":

    Running Qt Animation Application

    Is it really all that great?

    This article describes how to build the Qt Application SDK and how you can run a simple Qt application. We have not tested the Qt Application SDK more than what we described in this article. Testing all features of Qt is certainly possible, but our time is better spend adding low-level functionailty to our iMX6 BSP. We are certain there are more problems in the Qt source code than what we discovered so far; Windows Embedded Compact specific, but most probably also generic issues. Hopefully the final release of Qt 5.6 will solve a lot of the issues we have discovered. It's always good to participate and report issues to the Qt community, like we did as well. Current known issues we see in Qt 5.6 alpha are for instance:

  • qmlscene.exe sample application crashes. [update 18-12-2015] This is fixed now in the new patch
  • Visual Studio plugin is not accepting the Qt Application SDK build.
  • And probably some more...
  • Quick reference guide

    This is a summary of all the steps required to build the Qt Application SDK for the GuruCE iMX6 SDK:

    The Qt 5.6 alpha source tree location: H:\qt-everywhere-opensource-src-5.6.0-alpha
    The Qt working directory: H:\Qt\QT5.6a

    Nr. Description Command
    1 Make sure you meet the prerequisites and QT5.6a code tree is extracted (e.g. H:\qt-everywhere-opensource-src-5.6.0-alpha) -
    2 Download and extract the Qt56alpha_patches.zip file in the root of the QT5.6a source tree -
    3 Open a command prompt in the root of the Qt source code tree and run the patches: \H:\qt-everywhere-opensource-src-5.6.0-alpha\patch\patch.bat
    4 Exit command prompt exit
    5 Open VS2013 or VS2015 Developer command prompt and navigate to the work directory cd H:\Qt\QT5.6a
    6 Run the Qt configure tool for Visual Studio 2013 configure -platform win32-msvc2013 -xplatform wince80GuruCE-armv7-msvc2013 -rtti -mp -ltcg -release -opensource -confirm-license -no-compile-examples -nomake tests -opengl es2 -openvg -skip qtandroidextras -skip qtactiveqt -skip qtsensors -prefix %CD%\SDK
    - or -
    6 Run the Qt configure tool for Visual Studio 2015 configure -platform win32-msvc2015 -xplatform wince80GuruCE-armv7-msvc2015 -rtti -mp -ltcg -release -opensource -confirm-license -no-compile-examples -nomake tests -opengl es2 -openvg -skip qtandroidextras -skip qtactiveqt -skip qtsensors -prefix %CD%\SDK
    7 Build the SDK nmake
    8 Install the SDK nmake install
    9 Download and extract the qt.conf.zip file. Copy qt.conf to SDK\bin -
    10 Copy/FTP the Qt Application SDK to the device (~420MB) -
    11 Telnet to the device telnet 192.168.2.15
    12 Navigate to SDK location cd \sd\SDK\bin
    13 Run the animation sample qml ..\examples\quick\animation\animation.qml

    Update October 2020

    Thanks to Stan Morris we can now provide an update to all of the above. There are two issues with the above instructions and patches:

    • Missing configure argument which expose crash defect QTBUG-87767
    • mkspecs settings result in debug build stability issues

    Regarding the crash defect in Qt related to the build instructions in this post, the “configure” command line needs the “-qreal float” argument.

    The Qt 5.6 defect involves evaluating an uninitialized “double” in QML. Stan wrote up the defect in QTBUG-87767.

    This post’s linked Qt56alpha_patches.zip file contains mkspec files that have bad settings for debug builds which cause stability issues when debugging. Specifically, it is the /MTd flag that causes a problem. You can read a little about it on stack overflow.

    Bad directives:


    QMAKE_CFLAGS_DEBUG += -Zi -MTd
    QMAKE_CFLAGS_DEBUG -= -MDd

    Corrected directives:


    QMAKE_CFLAGS_DEBUG += -Zi

    New GuruCE iMX6 BSP release 550 adds support for Freescale SABRE Smart Device Platform (SDP)

    GuruCE Logo

    To celebrate GuruCE becoming an official Freescale Proven Partner we added support for the Freescale SABRE Platform for Smart Devices Reference Design (DualLite & Quad) to our iMX6 BSP.

    Free downloadable WEC7 and WEC2013 evaluation kernels for the Freescale SDP-DL and SDP-Q, as well as a myriad of other supported boards can be found here.

    Some highlights of release 550:

    • Support for the Freescale SDP-DL and SDP-Q
    • Support for the new Boundary Devices Nitrogen6_VM
    • Further cache optimizations to improve real-time performance
    • Full support for Qt 5.5 on WEC7 and WEC2013
    • Better RS485 support
    • Added temperature monitor driver
    • Improved performance of FTP server code
    • Many more improvements, see the Release Notes for all the details

    Download our demo kernel images now and see for yourself why no other iMX6 BSP on the market today can compete with the quality, performance and stability of the GuruCE iMX6 BSP!

    Pages

    Subscribe to RSS - blogs