Changing motherboards

  • Thread starter Thread starter Doug Gordon
  • Start date Start date
D

Doug Gordon

Our PC supplier just informed us that our current product's motherboard has
gone obsolete and that they will be changing to a new board, which of course
means a different processor, glue chipset, etc. My XPE image has been
evolved over the past two years and I'd really hate to start over from
scratch.

What I could see doing at a minimum would be to run Target Analyzer on the
new system, make a new hardware macro component out of it, replace my
current h/w platform component with the new one, do dependencies, and
generate an image. But even though I removed my previous h/w macro, I would
guess that the modules that my old dependency check pulled in would remain
in the new image. I have the following questions about this:

a) Does this really hurt anything other than taking up a bit more disk
space? I would assume that FBA will take care of bringing in the drivers
that are actually required for the target board.

b) Is there a way to "clean out" the modules in my target config that are
not explicitly included and then re-run the dependency check from scratch?

c) What if I left *both* hardware macros in place? Would my resulting image
be loadable onto both target h/w platforms and FBA would sort it out? Having
to maintain different images for different h/w versions is going to make
life even more difficult for our production and maintenance departments.

Thanks for any advice. I'm sure that other people have faced this issue
considering how fast PCs evolve and become obsolete :-(.

Doug G
 
Doug,

The only thing I can contribute to this is my similar experience. I use one
image that contains 2 separate chip sets to support 2 different chassis. They
both are using ACPI multiprocessors but different chip sets on the mboard. I
had to support 2 separate post FBA images but one SLD file. The FBA loaded
the correct chip set and things have been working fine on both. However, I
could not do this for different processor types (i.e. ACPI and MPS). Luckily,
both chassis used ACPI. I have not tried this with different video
configurations. that is what i'm faced with next.

-Tim
 
Hi Doug,
Our PC supplier just informed us that our current product's motherboard has
Click to expand...
[skip]

As far as you use "standard" way (with PnP stage after reseal) all is OK.

we have 3 different XPe versions: for P3 based machines, for P4 based
machines and for XEON based one.

As far as I get appropriate drivers - the correct version boots on any
motherboard (of the same processor type) I ever saw. So far, let me
count, well, it was around ~15-20 completely different brands on which
one XPe image was installed successfully. In worst case I have some
devices are not recognized.

Device.pmq is not an idol to whom XPe prays. XPe has PnP capabilities
that allows it to support quite different hardware.
 
Doug,

First, depending on your product lifecycle & costs, I'd recommend
looking at some long-life PC motherboards. I just switched from an OTS
consumer grade motherboard to a long-life one, since our product (a
medical device) requires substantial certification and hardware changes
can be costly to retest, etc. Some manufacturers in this area are
American Predator are ITOX Applied Computing; I'm sure there are more.
(Note: they're not cheap!)

Your idea of supporting multiple chipsets should work as long as you've
got all the PnP components. However, you may lose some settings
depending on the device. For example, if you have a network device,
you will probably lose all of your network settings. I have also had
problems with video card settings, since PnP will reset the resolution,
etc. If your new motherboard has different a USB controller, you'll
probably lose all your USB device settings that don't automatically get
reinstalled (such as printers). If this is the case, you'll have to
come up with some creative solutions -- I wrote an XP service which
resets certain registry values at every boot.

One method I use is to separate all the non-hardware XPe components
from the hardware. In this way, it's fairly easy to create a new XPe
configuration if you need to migrate to new hardware. In other words:

1) Take your current configuration, remove all hardware-related
components, and reduce dependencies as much as possible (in other
words, strip out components that will get pulled in during a
dependcency check.) Save this as the "Base" configuration.
2) Use TAP.EXE to create a devices.pmq file, and then create a macro
component from this configuration.
3) To create your final config, load the "Base" config, then add the
hardware macro component. Save this as the "merged" config.

You can now repeat #2 & #3 fairly easily everytime you need to support
new hardware. In fact, you can easily create your "multi"-config by
adding several hardware macro components. As your configuration
evolves, you update the "Base" config first, then repeat #2 & #3 for
each set of hardware.

-- Don
 
Tim:
Yeah, this is probably what I will try to do. I do see that two post-FBA
images will have to be maintained due to some of the post-FBA, pre-reseal
customizations that I do that would be lost if the resealed image is booted
on the alternate platform. I am not sure yet just how different the new
platform is, so maybe after they get one in here for me to play with I can
make a final decision.

Doug G
 
Doug,

First, depending on your product lifecycle & costs, I'd recommend
looking at some long-life PC motherboards. I just switched from an OTS
consumer grade motherboard to a long-life one, since our product (a
medical device) requires substantial certification and hardware changes
can be costly to retest, etc. Some manufacturers in this area are
American Predator are ITOX Applied Computing; I'm sure there are more.
(Note: they're not cheap!)

Your idea of supporting multiple chipsets should work as long as you've
got all the PnP components. However, you may lose some settings
depending on the device. For example, if you have a network device,
you will probably lose all of your network settings. I have also had
problems with video card settings, since PnP will reset the resolution,
etc. If your new motherboard has different a USB controller, you'll
probably lose all your USB device settings that don't automatically get
reinstalled (such as printers). If this is the case, you'll have to
come up with some creative solutions -- I wrote an XP service which
resets certain registry values at every boot.

One method I use is to separate all the non-hardware XPe components
from the hardware. In this way, it's fairly easy to create a new XPe
configuration if you need to migrate to new hardware. In other words:

1) Take your current configuration, remove all hardware-related
components, and reduce dependencies as much as possible (in other
words, strip out components that will get pulled in during a
dependcency check.) Save this as the "Base" configuration.
2) Use TAP.EXE to create a devices.pmq file, and then create a macro
component from this configuration.
3) To create your final config, load the "Base" config, then add the
hardware macro component. Save this as the "merged" config.

You can now repeat #2 & #3 fairly easily everytime you need to support
new hardware. In fact, you can easily create your "multi"-config by
adding several hardware macro components. As your configuration
evolves, you update the "Base" config first, then repeat #2 & #3 for
each set of hardware.

-- Don
Click to expand...

Thanks, this is some good info, especially the part about losing some
settings if the resealed image is booted on the alternate h/w platform. The
idea of having a base image is also a good one, but I am not sure how to
accomplish your step #1 of stripping the hardware components and
dependencies. I can find the h/w components, but am not sure which of the
multitude of other components can be removed or not.

Doug G
 
If you create a macro component (as described in the XPe docs) from a
devices.pmq file, in Target Designer you will see a list of each
hardware device (with checkboxes) when you expand the the macro
component and select "Settings". Then just delete each of listed
components (note that they will appear in italics when they are still
included in your configuration.) Then remove the macro component
(since a dependency check will bring the hardware components back in!)

To get the "Base" configuration, it's pretty much an iterative,
try-and-see process. (That is, delete some components and see if they
come back during a dependency check.) I had also "grown" my config
into one large configuration. Some things are easy (e.g., if you use
the DirectX macro component, you can delete all the subcomponents
listed.) If you're not all that concerned about footprint, then I
wouldn't spend too much time; there's no real risk in having extra
components.

-- Don
 
Back
Top