Windows Embedded Home
Windows Embedded 8 Family
Windows Embedded 7 Family
Other Windows Embedded Products
ABOUT THE BLOGGER
David CampbellProgram Manager
David Campbell is a Program Manager on the Windows Embedded Compact team. David’s been at Microsoft since 1994 and has spent most of his time working on embedded software and hardware projects.
Posted By David CampbellProgram Manager
Welcome back! This is part 2 of Doug Boling’s great write-up on Understanding CEPC Boot Sequence in Windows Embedded Compact 7. Last time we covered the PC boot sequence in detail. That provides the background for the Windows Embedded Compact specifics. Let’s jump right in...
In Part 1, I started this discussion with an overview of two of the three different CEPC boot loaders provided in the Windows Embedded Compact 7. I discussed the LoadCEPC bootloader as well as how to use the BIOSLoader. I also talked about how the FAT file system. An understanding of the layout of a FAT storage device is important when understanding how these bootloaders work. In this installment, I will cover how the BIOSLoader and the WCELDR work and how to modify the WCELDR to adapt it to your hardware.
In Part 1, I discussed how the file system works, now let’s return back to the BIOSLoader to cover how it works. When the system starts, the BIOS will load the Master Boot Records (MBR) into RAM which will find and load the boot sector of the active partition. This boot sector will be one of the BIOSLoader boot sectors that will have to be installed on the disk. The source code for the BIOSLoader boot sectors is located in \WINCE700\platform\cepc\src\bootloader\biosloader\bootsector, There is a unique boot sector for each of the different File Allocation Table (FAT) formats including ExFAT.
The boot sector code finds the root directory and looks for the name BLDR with no extension. It expects to find this name in one of the first 32 entries in the root since the boot sector only reads the first sector of the root directory into memory.
When the BLDR entry is found, the boot loader finds the location of the file data by using the first cluster entries in the directory entry for the file. Instead of following the FAT chain to properly load the entire file, the boot sector assumes that the file will be stored in linear sectors on the disk and reads a fixed (68 sectors or 34816 bytes) into memory at address 0:1000. This hard coded size provides an absolute limit on the size of the BLDR code.
The boot sector then jumps to the first byte of the BLDR file. The BLDR then switches to protected mode and executes the remaining tasks from there. Those tasks include reading and parsing the BOOT.INI file and downloading or reading from the disk the NK.BIN file.
Comments Windows Embedded Compact
Doug Boling recently hosted one of his regular webcasts on Optimizing performance and power on Windows Embedded Compact 7 and has graciously provided me with a companion article. Thanks Doug! There’s more information later in the article about how you can sign up for these webcasts so please do join us for the monthly sessions.
Embedded hardware is slow. It’s designed that way. Unlike Personal Computers which are sold to customers who are dazzled by high gigahertz numbers and massive hard disks, embedded customers buy a widget that does something. If the widget does something well that’s all that matters, so the manufacturer of that widget is going to use the slowest (and often least expensive) hardware possible to implement that widget. This is one requirement that makes embedded software so challenging to write. Embedded software must have great performance so that the hardware can be as inexpensive as possible.
In this blog post, I will review some of the techniques for system design that can improve performance, and as a consequence, the power consumption of a system. I’ll also cover some lower level application driver characteristics that can lower power consumption directly.
At the recent Visual Studio launch event, it was confirmed that Visual Studio 2012 will once again include support for Windows Embedded Compact. Included in that support we’re targeting much of the newest compiler and tools functionality, most notable of which includes new compiler features such as C++11 language standards, faster more efficient code generated, an updated CRT, auto-parallelization and auto-vectorization (Wow, that’s a mouthful.), range based loops, RValue references, and more. Also included will be an updated version of .net CF which has greatly improved performance, particularly around memory allocation and garbage collection - using the “generational” garbage collector. This not only provides more performance, but more predictability in the execution of applications.
More information about the new Visual Studio, including support for Compact, can be found at the Visual Studio Launch site. (Yes, I’m in the video and no, I’m not going to be able to make a living in front of the camera. But it’s the message that’s important here.)
Be sure to check back in the future as we release more information on the upcoming Windows Embedded Compact release.
In a previous post, I discussed the Windows Embedded Compact 2013 announcement and a number of great new features in the OS and tools. With those posts, I received a number of questions about the tools. As you all know, Windows Embedded Platform builder (PB) is a plug in to Visual Studio. For Windows Embedded Compact 7, our Platform Builder plug in and tools were hosted by Visual Studio 2008, while Platform Builder in Windows Embedded Compact 2013 will be hosted in Visual Studio 2012. A number of people asked whether PB from Windows Embedded Compact 7 could be hosted in Visual Studio 2012, or alternatively whether PB from Windows Embedded Compact 2013 can target Windows Embedded Compact 7. Unfortunately, the answer to that is no. There had to be significant changes to both Windows Embedded Compact 2013, including PB, as well as Visual Studio 2012 to support the latest versions of each. The hosting has changed, and more importantly, the compilers and ABI (Application Binary Interface) to the ARM chipset has changed and are incompatible with each other. Even though each version of Windows Embedded Compact 7 can target the same chipset in this case, the compilers from each cannot support the other. More information will be posted on this in a future article.
While the Windows Embedded Compact 2013 announcement is certainly exciting, we want to continue posting great information on Windows Embedded Compact 7 as well. To that end, we have another great in-depth article from Doug Boling to share.
Microsoft Platform Builder is a tool that anyone who ports Windows Embedded Compact will live in throughout the project. (PB is also used when creating new device images from scratch. This information certainly applies to that scenario as well.) Given the time spent in this tool, it’s critical that your development machine be properly configured to maximize the performance of the tool and by implication your performance.
I’ve seen a number of questions in some of the forums about how to get started with Windows Embedded Compact from the perspective of running (hosting) the actual OS image created with Platform Builder (PB). PB makes it easy to design and create an embedded OS image, but you still need to be able to load and execute that image – typically on a piece of hardware.. Virtual PCs are great as a Windows Embedded Compact development tool since they don’t actually require new hardware. Virtual machine use with Windows Embedded Compact really falls into two categories: hosting an OS image and hosting PB itself. The one I’ll cover today is hosting an embedded OS image, built with PB, in a Virtual PC rather than on an actual device.