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.
As the Windows Embedded Compact v.Next launch approaches, we will soon be posting detailed information about the Compact OS and tools, both Platform Builder (used for Board Support Packages (BSPs) as well as drivers) and the use of Visual Studio itself for developing applications on top of Compact OS images. I’m looking forward to making more of the technical details of the release available, probably in small bits until we can go fully public, which will happen very soon.
In the meantime let’s take a detailed look at the CEPC BSP. Here’s a guest post by Doug Boling again with a great overview based on his recent webcast. (More details on Doug’s webcast series are provided at the end of the article.)
The CEPC board support package (BSP) in Windows Embedded Compact 7 is one of the frequently used BSPs in Platform Builder. Unfortunately it is also one of the more difficult to customize. It may seem strange to customize a BSP that runs on a generic PC chassis but when used on a production embedded system, some form of customization such as splash screens or subtle changes in hardware is almost always necessary.
The difficulty in customizing the CEPC BSP comes from its file structure. Before I can explain the problem, I need to discuss the architecture of a standard Windows Embedded Compact BSP
Welcome to the “new and improved” :) Windows Embedded Compact blog! This is part of our new, consolidated Approaching Embedded Intelligently blog effort to provide updated content, consolidate existing content, feature guest bloggers and, most importantly, provide a common place to get updated information.
As a quick introduction, I’m David Campbell; I’m a Program Manager (PM) on the Windows Embedded Compact team. I’ve been involved with Windows Embedded Compact/Windows CE since Windows CE 1.0 as a PM. Over the years I’ve been responsible for a variety of technologies, and most recently I’ve been driving the overall releases.
The Windows Embedded Compact team’s mission has evolved over the years, but a large portion of our mission and goals remain the same. We continue to provide a Microsoft OS solution for high volume, small footprint, real-time devices. An OS that is stable & reliable, with a long support cycle and ideal for high availability devices. Windows Embedded Compact fits into Microsoft’s overall offerings with its APIs and tools aligning with Windows to provide a familiar development experience right out of the box.
There have been a number of great bloggers for Compact over the years and I encourage you to read them, including Olivier Bloch, Sue Loh, Steve Maillet, Mike Hall, and Doug Boling to name a few. While some of our bloggers haven’t posted in a while, much of the information remains relevant; this is a testament to the stability and longevity of the Compact product. It also shows how dispersed the information is, which is something we’ll try to improve with these articles.
Embedded OEMs and developers often struggle with how to bring up hardware to quickly begin work on their overall solutions. Often, product requirements limit platform options and require extensive development time and costs. Windows Embedded partner Toradex has a great solution to this challenge. Toradex specializes in embedded hardware and software, and with Windows Embedded Compact, Toradex is able to provide solutions that can be not only used to quickly bring up your product, but also provide cost-effective hardware with which you can ship your product.
Toradex has a line of boards and modules that are both standardized and flexible. The Colibri hardware design scales from 208 MHz up to 1 GHz nVidia Tegra 3 and allows hardware updates by just swapping these standardized, pin-compatible modules. A very cool design! Standardization allows costs to be reduced, and it’s flexible enough to be used in a large variety of devices and industries, ranging from industrial automation and control to aerospace and medical. Toradex sells exclusively over the Internet and ships worldwide. And because of their redundant manufacturing facilities around the world, they can provide a reliable supply chain.