use breakpoints for thorough debugging, run Tux.exe directly on the target device in standalone mode, as mentioned earlier in this lesson. You can display the required command line in the workstation server application when you right-click the test and select Edit Command Line.
Analyzing CETK Test Results
CETK tests should use Kato to log test results, as demonstrated in the skeleton Tux module:
g_pKato->Log(LOG_COMMENT, TEXT('This test is not yet implemented.'));
The workstation server application retrieves these logs automatically through Clientside.exe and stores them on the development workstation. You can also access these log files through other tools. For example, if you are using CETK in stand-alone fashion, you can import the log files to the development workstation by using the File Viewer remote tool.
The CETK includes a general CETK parser (Cetkpar.exe) located in the C:Program FilesMicrosoft Platform Builder6.00CepbWcetk folder for convenient viewing of imported log files, as shown in Figure 4-13. Typically, you start this parser by right- clicking a completed test in the workstation server application and selecting View Results, yet you can also start Cetkpar.exe directly. Some tests, particularly performance tests based on PerfLog.dll, can also be parsed into comma-separated values (CSV) format and opened in a spreadsheet to summarize the performance data. The CETK includes a PerfToCsv parser tool for this purpose, and you can develop custom parsers for special analysis scenarios. Kato log files use a plain text format.
Figure 4-13 Analyzing CETK test results
Lesson Summary
The Windows Embedded CE Test Kit is an extensible tool that enables you to test drivers and applications on a target device in connected mode and in standalone mode. Running the CETK tools in standalone mode is useful if the target device does not support connectivity over KITL, ActiveSync, or TCP/IP. Most typically, developers use the CETK to test device drivers added to the BSP of a target device.
The CETK relies on the Tux test engine, which provides a common framework for all test DLLs. The Tux DLLs contain the actual testing logic and run on the target device to load and exercise the driver. Tux DLLs also interface with Kato to track test results in log files, which you can access directly in the CETK test application or process in separate tools, such as custom parsers and spreadsheets.
Lesson 4: Testing the Boot Loader
The general task of a boot loader is to load the kernel into memory and then call the OS startup routine after powering up the device. On Windows Embedded CE specifically, the boot loader is part of the BSP and in charge of initializing the core hardware platform, downloading the run-time image, and starting the kernel. Even if you do not plan to ship a boot loader in your final product and directly bootstrap the run-time image, you might find a boot loader helpful during the development cycle. Among other things, a boot loader can help to simplify run-time image deployment complexities. Downloading the run-time image over Ethernet connections, serial cable, DMA, or USB connections from a development computer is a convenience feature that can help to save development time. Based on the source code included with Platform Builder for Windows Embedded CE 6.0, you can also develop a custom boot loader to support new hardware or features. For example, you can use a boot loader to copy the run- time image from RAM into flash memory and eliminate the need for a separate flash memory programmer or Institute of Electrical and Electronic Engineers (IEEE) 1149.1-compliant test access port and boundary-scanning technology. However, debugging and testing a boot loader is a complex undertaking because you are working with code that runs before the kernel loads.
After this lesson, you will be able to:
¦ Describe the CE boot loader architecture.
¦ List common debugging techniques for boot loaders.
Estimated lesson time: 15 minutes.
CE Boot Loader Architecture
The underlying idea of a boot loader is to bootstrap a small program with pre-boot routines in linear, nonvolatile, CPU-accessible memory. Having placed the initial boot loader image on the target device at the memory address where the CPU begins to retrieve code through a built-in monitor program provided by the board manufacturer or a JTAG probe, the boot loader runs whenever you power up or reset the system. Typical boot loader tasks performed at this stage include initializing the Central Processing Unit (CPU), the memory controller, system clock, Universal Asynchronous Receiver/Transmitters (UARTs), Ethernet controllers, and possibly other hardware devices, downloading the run-time image and copying it into RAM according to the binary image builder (BIB) layout, and jumping to the StartUp function. The last record of the run-time image contains this function's start address. The StartUp function then continues the boot process by calling the kernel initialization routines.
Although the various boot loader implementations differ in their complexity and the tasks they perform, there are common characteristics that Windows Embedded CE covers through static libraries to facilitate boot loader development, as illustrated in Figure 4-14. The resulting boot loader architecture influences how you can debug boot loader code. Chapter 5, 'Customizing a Board Support Package,' discusses boot loader development in more detail.
Figure 4-14 Windows Embedded CE boot loader architecture
The Windows Embedded CE boot loader architecture is based on the following code portions and libraries:
¦ BLCOMMON Implements the basic boot loader framework for copying the boot loader from flash memory to RAM for faster execution, decoding image file contents, verifying checksums, and keeping track of load progress. BLCOMMON calls well-defined OEM functions throughout the process to handle hardware- specific customizations.
¦ OEM code This is the code that OEMs must implement for their hardware platforms to support the BLCOMMON library.
¦ Eboot Provides Dynamic Host Configuration Protocol (DHCP), Trivial File Transfer Protocol (TFTP), and User Datagram Protocol (UDP) services to download run-time images over Ethernet connections.
¦ Bootpart Provides storage partitioning routines so that the boot loader can create a binary ROM image file system (BinFS) partition and a second partition with another file system on the same storage device. Bootpart can also create a boot partition to store boot parameters.
¦ Network drivers Encapsulate the basic initialization and access primitives for a
