共用方式為

Leveraging multi-boot scenarios with Windows Embedded Standard

  • 發行項

**Updated 3/26/09 with preface

[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.]

Depending on your project it can be a good idea to have more than one operating system instance in place on an embedded system. Looking at Windows Embedded Standard there are several scenarios supported, each with its own pros and cons which I will highlight in this blog post.

Important settings in the boot.ini

It is no secret that the boot.ini is of major importance in to the process of booting a system. Thinking about multi-boot, it is one of the central files, because all available OS instances need to be configured here.

A normal boot.ini file to boot a single OS image looks similar to this (at least on non SCSI systems):

[boot loader]

timeout=0

default=multi(0)disk(0)rdisk(0)partition(1)\Windows

[operating systems]

multi(0)disk(0)rdisk(0)partition(1)\Windows="Microsoft Windows Embedded Standard" /fastdetect /noexecute=AlwaysOff

In the boot loader section a timeout value shows the time the number of seconds the boot menu is displayed (in this case 0 seconds) as well as the default operating system instance into which the system boots when the timeout has elapsed, and no other instance has been manually chosen.

In the operating system section all OS instances are specified using the ARC path naming conventions. ARC is the abbreviation of Advanced RISC Computing, a specification that dates back to long before the first NT kernel has been was developed.

The detailed specification can be viewed in the link above, but the important things to remember are the rdisk entry, which specifies the disk, and the partition entry, which specifies the boot partition.
Please keep in mind that the numbering of disks and partitions is a bit out of sync - disks start with 0 and partitions start with 1. In the example above disk(0), therefore, means the first disk and partition(1) is the first primary partition on the disk.
Right after the disk and partition information, and with no space in-between, the path to the Windows folder is required. It needs to be included without drive letter. The drive is already qualified with the preceding entries.

SCSI system require a SCSI(0) entry instead of Multi(0).

Creating a multi-boot boot.ini

OS instances can be created on the same disk and partition (but in a different folder), on the same disk in another partition or on another disk. What all these options have in common, is that the boot loader (NTLDR), as well as the boot.ini, must reside on the same boot partition (very often the first partition on the first disk).
Note -the boot partition is not specified in the boot.ini. It is defined by marking it active using a disk utility such as diskpart.

A few examples:

  • The entry for an instance installed to the WES folder.

multi(0)disk(0)rdisk(0)partition(1)\WES="Microsoft Windows Embedded Standard" /fastdetect /noexecute=AlwaysOff

  • The entry for an instance on a second partition

multi(0)disk(0)rdisk(0)partition(2)\Windows="Microsoft Windows Embedded Standard" /fastdetect /noexecute=AlwaysOff

  • The entry for a Windows Embedded Standard image on a second disk and on a second partition

multi(0)disk(0)rdisk(1)partition(2)\Windows="Microsoft Windows Embedded Standard" /fastdetect /noexecute=AlwaysOff

As an example, to have a working multi-boot system, these types of entries need to be added to the operating system section of the boot.ini:

[boot loader]

timeout=10

default=multi(0)disk(0)rdisk(0)partition(1)\Windows

[operating systems]

multi(0)disk(0)rdisk(0)partition(1)\Windows="Microsoft Windows Embedded Standard" /fastdetect /noexecute=AlwaysOff

multi(0)disk(0)rdisk(0)partition(1)\Maintain="Microsoft Windows Embedded Standard Maintenance OS" /fastdetect /noexecute=AlwaysOff

multi(0)disk(0)rdisk(1)partition(1)\Maintain="Microsoft Windows Embedded Standard Lean System" /fastdetect /noexecute=AlwaysOff

These settings offer the choice between three OS instances- a normal Standard system, a maintenance system and a leaner system, with a boot menu set for 10 seconds.

So, when is it good to have multi-boot capabilities?

Dual Boot Development

One of the scenarios is dual boot development, where a normal XP Pro system could reside on disk as first instance and the Windows Embedded Standard image created using it goes to a second partition. This comes in handy for testing because the image is easy to deploy, but it also requires a capable processor and enough RAM to run target designer on the target. Additional drawbacks are that the development system (XP Pro) cannot be used while the new image runs through FBA and the path information has to be adapted to the real target layout before field deployment.

Maintenance

A much better scenario for having more than one OS instance on the embedded system is maintenance. Having a special maintenance OS at hand can be very beneficial if one wants to add more robustness and control to the change management process.

Different Device Usage modes

From an OEM perspective it sometimes makes sense just to have one type of device on stock that is able to adapt to different usage scenarios. Here Windows Embedded Standard multi-boot offers flexibility. A universal device can be developed that adjust to the needs of a certain role just by editing the boot.ini to use the fitting OS instance to boot from. This option requires some additional storage space, of course, but this is cheap nowadays, or?

- Alexander

Alexander Wechsler

Wechsler Consulting

www.wechsler-consulting.de

Technorati Tags: Xpe,embedded

Comments

  • Anonymous
    November 28, 2008
    PingBack from http://blog.a-foton.ru/index.php/2008/11/28/leveraging-multi-boot-scenarios-with-windows-embedded-standard/

  • Anonymous
    November 29, 2008
    This is a nice feature/scenario. Especially the maintenance OS start me thinking for several devices. But are you allowed to run multiple instances of the OS with a single PID? And does this also work for XP Embedded?

  • Anonymous
    December 01, 2008
    For each instance of XP Pro you would have to have a unique PID. For each instance of XP Embedded you would need a license (COA sticker on the machine, obtainable from your distributor). Thanks, Lynda

  • Anonymous
    December 23, 2009
    The comment has been removed

  • Anonymous
    December 28, 2009
    You need to make sure you have set your drive in TD to the correct drive letter as well e.g. D:

  • Anonymous
    May 02, 2010
    Hy, I have the same problem like Shahroon Saleem. Which drive letter has to be set in the TARGET DESIGNER?!? Thanks

  • Anonymous
    May 03, 2010
    Hi Shahroon and Tom, I would like to suggest the following settings in TD (settings node at the top of the configuration pane - target device settings): Boot drive - C: Windows folder - D:WINDOWS Prog Files - D:Program Files Dokuments and Settings - D:Documents and Settings ARC Path - multi(0)disk(0)rdisk(1)partition(1) The important thing to remember is that you still boot from C: as NTLDR resides there. NTLDR then reads the contents of the boot.ini. Which correctly should point to disk 1, partition 1 (drive D: - make sure that there no hidden partitions on disk 2). Hope that helps Alexander