Creating global system configurations
[The following article is authored by one of the Windows Embedded MVPs (Most Valuable Professionals). Our MVPs have a heavy background in Embedded systems and are a great repository of information on Windows Embedded products. We’re providing this space on our team blog as a service to our readers by allowing MVPs to share some of their knowledge with the rest of the community.]
Any time an OEM creates not only a single Windows Embedded Standard device, but a family of devices, the question is whether there could be a single base image for the complete range of systems. This is a compelling idea, because maintaining just a single image streamlines product development efforts. The answer is “Yes” - under certain circumstances. All systems should not require special configuration or footprint optimization and, most importantly, should utilize the same HAL, such as Standard PC or ACPI Multiprocessor PC.
HAL
HAL is the Hardware Abstraction Layer that adapts the hardware-agnostic Windows Embedded operating system to the hardware provided by the OEM. Due to the fact that this software layer resides on a very low level, the correct HAL is always required to boot the system. In contrast with the installation of most drivers, mechanisms such as Plug & Play do not work for the HAL component, because the system is not up and running at the time the services of the HAL are required.
There are several HALs available in Standard (see above) and the best way to choose one is to run TAP.exe on the target system. If devices in a device family require different HALs, it is normally not possible to create a common basic image for them, because there can only be one HAL at a time in an image configuration. Sometimes, HALs are interchangeable and one might be lucky to get a system running with a different HAL than proposed by TAP (often Standard PC), although it is more likely that the device will blue screen during boot . Nevertheless, it is always worth a try.
Drivers
If you are lucky enough to have the same HAL on the devices, drivers are the next issue that needs to be solved. Different systems naturally do require different drivers and TAP.exe does a great job of collecting the driver information from each target system in a device family into a .PMQ file. A good way to create a global hardware component out of the dedicated driver information from all the .PMQ files is to copy the driver information from each .PMQ into a single .PMQ file.
<?xml version="1.0" ?>
<!DOCTYPE HIB (View Source for full doctype...) >
- <!--
-->
- <!--
-->
- <HIB DTDRevision="4">
- <TOOLINFO>
<PLATFORM>Microsoft Windows XP</PLATFORM>
<TOOL>Target Analyzer Probe Version 2.00.1500.0</TOOL>
<TOOLOPTIONS>"C:\Program Files\Windows Embedded\utilities\tap.exe"</TOOLOPTIONS>
<TIMESTAMP>2008-10-27, 11:49:59AM</TIMESTAMP>
</TOOLINFO>
- <DEVICES>
- <CATEGORY Name="ACPI">
- <DEVICE ConfigFlags="0">
<DEVICEDESC>@battery.inf,%acpi\acpi0003.devicedesc%;Microsoft AC Adapter</DEVICEDESC>
- <HARDWAREIDS>
<DEVICEID Order="1">ACPI\ACPI0003</DEVICEID>
<DEVICEID Order="2">*ACPI0003</DEVICEID>
</HARDWAREIDS>
<COMPATIBLEIDS />
</DEVICE>
- <DEVICE ConfigFlags="0">
<DEVICEDESC>@cpu.inf,%intelppm.devicedesc%;Intel Processor</DEVICEDESC>
<FRIENDLYNAME>Intel(R) Core(TM)2 Duo CPU T9300 @ 2.50GHz</FRIENDLYNAME>
- <HARDWAREIDS>
<DEVICEID Order="1">ACPI\GenuineIntel_-_x86_Family_6_Model_23</DEVICEID>
<DEVICEID Order="2">*GenuineIntel_-_x86_Family_6_Model_23</DEVICEID>
<DEVICEID Order="3">ACPI\GenuineIntel_-_x86_Family_6</DEVICEID>
<DEVICEID Order="4">*GenuineIntel_-_x86_Family_6</DEVICEID>
<DEVICEID Order="5">ACPI\GenuineIntel_-_x86</DEVICEID>
<DEVICEID Order="6">*GenuineIntel_-_x86</DEVICEID>
</HARDWAREIDS>
- <COMPATIBLEIDS>
This file should not contain duplicate DeviceIDs to enable an error-free import into Component Designer when creating the hardware macro-component. Before moving on, you must componentize all device drivers that were not recognized during the import of the .PMQ into Component Designer. As soon as this has been done and the custom driver components have been imported into the database, re-import the .PMQ file into Component Designer, so that the missing drivers will be detected and resolved in the newly created hardware macro. Finally, import the hardware macro into the database.
The benefit of using this approach is that all drivers required by the device family will be part of the OS image and in the Plug & Play phase during FBA the correct ones for the current system will get installed. The other drivers will reside unused on the disk and will do no harm other than increasing the image footprint.
Software
There is no need to stop at hardware. The concept of grouping blocks of functionality in macro components can enable you to configure software functionality in target versions quickly and easily. The grouping can be done using a device-related approach, but often grouping components belonging to certain functionality elements is equally efficient. Microsoft showcases this quite well e.g. with their Media Player macro component.
Using functionality macros can be greatly beneficial to customers who require different OS functionalities for different scenarios on the same device. In this case skillfully created macro components are the best way to guarantee an agile image creation process.
Alexander Wechsler
Wechsler Consulting
Technorati Tags: XPe,Standard 2009