Windows CE OS Migration: Developing Your Legacy Windows CE Environment for the Future

As end-of-life dates for Windows CE and Mobile OS continue to get closer, our series Windows Embedded Compact Migration: What You Need to Know examines the primary issues around planning for the lack of support/extended support for Microsoft Embedded devices.

In Part 1 of the series, we surveyed the landscape for Microsoft Embedded and how to carefully consider OS Migration and priorities such as security updates and platform longevity.

So, in Part 2, let’s look some more at topics around OS migration.

Part 2: OS Migration – developing your legacy Windows CE environment for the future

Learn what to expect when moving from Microsoft to Linux Embedded. Here we explore the differences and similarities between the two operating systems.

For those from a Microsoft Embedded background, the move to using Linux can be a path that holds many options and isn’t necessarily clear.

Linux is made to be a flexible and scalable system. There are choices from the build system, kernel and many others right through to the way applications are launched on start-up.

Although versions of Windows Embedded boast a considerable amount of features, they pale in significance when compared to the reconfigurability of Embedded Linux.

The main core pieces in the OS remain the same for both systems –  bootloader, kernel and filesystem:

Windows CE wraps the kernel and filesystem together into an NK.BIN file, and Linux splits these into a kernel file and a root filing system (all the user-level drivers, applications and features). From a conceptual level, this is not so different.

Linux allows for a much greater level of flexibility with uboot having native support to read and write FAT partitions; this allows systems to leverage multiple kernels, configuration files, and splash screens without having to allocate blocks of reserved flash for each purpose, as is commonly done in CE.

The first choice on the OS (after you have selected the CPU) is the development tool. Typically, Yocto is used to build the OS components, drivers and configuration of the system. It allows a great level of control and the creation of smaller targeted Linux builds.

Like Windows CE, the Linux system can have a very simple bootloader or perform complex tasks prior to launching the kernel. uboot in Linux gives much more out-of-the-box support than eboot normally included from WinCE. This includes partitioning to support storage of splash screens and kernel images, network support for debug and boot support through to security features such as secure boot for hardware signing.

uboot can be customised to support multiple kernel images for redundancy – a great addition if you have the available storage space.

Also akin to Windows CE, Linux has a file system with all the configured applications included. These are in a separate file system compared with the NK.BIN. This allows changing of files which are core to the system.

How to Partition Embedded Linux

We’d recommended a number of partitions to separate the root file system from user data; in this way, these partitions can be erased without changing system files.

A further move from this is to have dual filesystems; this allows running from an ‘active’ bank while updating a second ‘inactive’ partition. On a successful update, the banks can be switched, which will allow booting from the new image; any failure in the update process will not leave the system in a broken state.

As the updates can be 10-100s MB in size this is a very useful feature to implement.

It goes without saying that all the Linux BSPs are built on a desktop Linux system. Unlike Windows CE, which builds some sources and links to the binary libraries from Microsoft, the Linux system compiles everything – kernel, drivers, application – from source.

A full clean build can lead to extended build times. Building and debugging in a smart way is essential to cut down wait times. Having the right build tools is also essential.

At ByteSnap, we employ a number of build servers with shared iSCSI NAS racks, moving customer VMs between servers to even loads. Using a 24-core Xeon with a 48GB RAM disk for building can build a typical Yocto release in 30-45 minutes. The same could take 24 hours on a laptop.

OS development should also focus on revision control to track changes. Due to the large number of source files in a BSP, the remote repositories used to build a Linux BSP can be unreliable.  Again, having a cache of these is important ensure that a build can be reproduced for a customer.

We deploy a warehouse system that is used to cache remote downloads, so that any build released to customers can be reproduced with all packages even if some cloud servers aren’t available or a brunch of code is updated to a new version.

ByteSnap have dedicated OS engineers and can advise on anything from OS selection, build configuration, custom drivers and more.
To find out more about our embedded Linux development services call ByteSnap on +44 121 295 5400
Our consultants are here to help.

Look out for the final instalment in our series, where we delve into Application Development and the migration of Windows CE to a new embedded environment…

Migrating a Windows Embedded Application or Project?

This checklist provides an overview of the steps required to migrate your Windows Embedded project, as well as lots of shortcuts you can take to reduce stress and the time required:

How can ByteSnap help you today?
From start-ups to blue chips, ByteSnap’s embedded systems developers are enabling companies to stay a step ahead by providing them with bespoke solutions. Maintain your competitive edge – contact us today and find out how we can optimise your product development!