Two boards with Intel cards (855 and 915) = hell

  • Thread starter Thread starter heidi.linda
  • Start date Start date
H

heidi.linda

Our suppliers have changed the motherboard they're putting into units
they supply us, so we have a mixed estate that I must support with a
single image - the cases are identical, so expecting the engineers who
put the disks in to work out which type of machine they're using for
initial setup or repair would be asking for trouble.
FBA on individual units isn't an option because there's far too much
post-FBA setup involved and it would take far too long.
Both boards have Intel graphics controllers. One has a laptop
controller the other an embedded controller, an 855 and a 915. Each
one will work individually without problems, but I can't make an image
work on both, even with drivers like the .4497 version mentioned in
another thread which *should* work on both cards. If I try using two
different drivers, if I set up on motherboard A first, then on
motherboard B, both work, but then as soon as that image is put back
into a motherboard A machine (or vice versa), I'll get a bluescreen
with different files causing the error according to which machine I
used first. When using a single driver, I have a similar problem - the
machines will both work when initially set up, but then as soon as the
disk is put back into the first machine I set up, the screen will
either go completely blank or corrupt and pink (though in both cases
it looks fine via VNC) and nothing I do will fix it, or if it does, it
then won't work on the other machine.
It doesn't seem to be related to trying to use a non-existent non-VGA
output, because on VNCing in, it will usually refer to being on
'default monitor' rather than the panel, or if it says panel, getting
it to revert to 'default monitor' usually won't get the display
functioning again. Nor does switching to the secondary monitor help,
and in some cases, the second monitor just won't enable - as soon as I
accept changes, it reverts to the primary monitor.
Scripts that run on first boot after sealing might work, except that
firstly, I'm told that repair engineers will sometimes move disks
between a working and problematic machine when diagnosing problems
(and if this happens when the machines have different motherboards,
both are going to end up broken) and secondly that when freshly
installed, the drivers tend to default to the wrong resolution, and
the engineers don't have keyboards or touchscreen access to the
display control panel.
I've not had any problems supporting multiple different setups before,
so management are assuming that I'm going to pull a solution to this
out of my hat and after a couple of weeks fighting with it, and with a
big project for another manager demanding my time as well, I'm about
at the end of my tether.
 
I'm afraid your best option is for your engineers to take the time to
identify which motherboard they are working with, and have two separate final
images. You can certainly support multiple chipsets in the same FBA image as
I'm sure you already know, but in every case that I've ever tried switching
an post FBA image between different hardware is going to cause headaches.

You can try running FBReseal (if the image hasn't already been resealed) and
hope that the PnP phase will set everything up right on the new hardware.
But again I've ran into problems here, primarily with the network adapter or
disk controller driver. And it would also require that you're able to run
FBReseal before moving the drive to a new system, if the system is not
booting it's not much help.
 
Each
one will work individually without problems, but I can't make an image
work on both, even with drivers like the .4497 version mentioned in
another thread which *should* work on both cards. If I try using two
different drivers, if I set up on motherboard A first, then on
motherboard B, both work, but then as soon as that image is put back
into a motherboard A machine (or vice versa), I'll get a bluescreen
with different files causing the error according to which machine I
used first.
Click to expand...

This is normal; when the image has been used on the target system, it
MUST NOT been put into another machine any more.

The trick is that after on one machine everything is set up as wanted
I take a new formatted CF and copy all the files to it with xcopy or
with file explorer manually, so the windows thinks while booting first
time it is new on this machine. Now I have my virgin image, secure it
into an image file with winhex and just copy it to new flashdisks.

When a new unit is assembled, is gets the virgin image, takes for
first booting a bit longer until all drivers and the EWS have settled,
makes a controlled reboot (done with our own application, but also
reboot.exe should do it), and then it is just fine, never mind, if it
was board type A or B.

Ralph.
 
This is normal; when the image has been used on the target system, it
MUST NOT been put into another machine any more.

The trick is that after on one machine everything is set up as wanted
I take a new formatted CF and copy all the files to it with xcopy or
with file explorer manually, so the windows thinks while booting first
time it is new on this machine. Now I have my virgin image, secure it
into an image file with winhex and just copy it to new flashdisks.

When a new unit is assembled, is gets the virgin image, takes for
first booting a bit longer until all drivers and the EWS have settled,
makes a controlled reboot (done with our own application, but also
reboot.exe should do it), and then it is just fine, never mind, if it
was board type A or B.

Ralph.
Click to expand...

Doing it that way isn't an option, we have a 'base' post-FBA, post-
additional-hardware image that then has a load of guff put onto it
with a content management app which turns it into a particular variant
of our product, *then* it gets sealed and off it goes to the
production line.
I've never had any problems supporting multiple hardware before, as I
said (apart from having to split to two different images for two
different product families due to one of one set of machines
identifying as multiprocessor and not being able to use the USB
properly if it wasn't set as that and one of the machine types in the
other product family bluescreening with the multiprocessor hal stuff.
Separating those out for the engineers is pretty trivial because one
lot are basic silver boxes and the other are rather nifty little
things with integrated screens.) it's just these Intel grapics cards.
The image I use for the larger, more mature product family supports
four different motherboards and eight different graphics cards, four
network cards etc (continuity of supply? Ha!) and, I was surprised to
note when I'd been messing about and picked up the wrong disk, it's
only two drivers short of working perfectly on my dev system as well.
So usually, it's not an issue, but then, mostly we're using ATI
graphics cards, and they're all using the same driver - it's just a
matter of making sure they're all set up at the right resolution, then
swapping them about between hardware variants doesn't cause any
trouble at all. It's extremely annoying to find that Intel can't
manage the same thing.
 
I'm afraid your best option is for your engineers to take the time to
identify which motherboard they are working with, and have two separate final
images. You can certainly support multiple chipsets in the same FBA image as
I'm sure you already know, but in every case that I've ever tried switching
an post FBA image between different hardware is going to cause headaches.

You can try running FBReseal (if the image hasn't already been resealed) and
hope that the PnP phase will set everything up right on the new hardware.
But again I've ran into problems here, primarily with the network adapter or
disk controller driver. And it would also require that you're able to run
FBReseal before moving the drive to a new system, if the system is not
booting it's not much help.
Click to expand...

Yeah... running FBReseal in that way would make the thing completely
useless to us, because the images *must* have the right settings on
out of the box. The less our engineers have to think the happier they
are, and to be honest when your'e rolling out several hundred
machines, the last thing you need is to have someone manually doing 10
minutes of configuration. The only thing we let FBReseal do, really,
is change the ssids and machine name. I guess I must just have been
lucky before in not having any problems with any combinations of
hardware I've tried, except in the one instance where one machine
required the image to be set as multiprocessor PC or the USB didn't
work while another (one of these -ing intels, as it happens)
bluescreens or hangs with that hal.
I suppose we'll just have to get the supplier to put a sticker
somewhere prominent on the new PC type, because it really isn't
obvious from the outside which machine type it is. To make things
easier for the engineers, the drives are on a little screw-in plate,
so they don't get to see the actual motherboard...
 
Doing it that way isn't an option, we have a 'base' post-FBA, post-
additional-hardware image that then has a load of guff put onto it
with a content management app which turns it into a particular variant
of our product, *then* it gets sealed and off it goes to the
production line.
Click to expand...

We also have much additional stuff, that is included with registry
tweaks (e.g. for gfx resolution), scripts and own programs, this is
also done in this process while the virgin image is booting the first
time; just did not mention it because it makes no difference to the
general process. We even have to recognize, if A or B, and install
some stuff depending on this recognition.

Ralph.
 
We also have much additional stuff, that is included with registry
tweaks (e.g. for gfx resolution), scripts and own programs, this is
also done in this process while the virgin image is booting the first
time; just did not mention it because it makes no difference to the
general process. We even have to recognize, if A or B, and install
some stuff depending on this recognition.

Ralph.
Click to expand...

I'd *like* to have a scripted install of the graphics drivers at
install time (rather than creation time) but the engineers whine
enough about how long it takes the units to first-boot, anything that
makes the process longer and they'll kick up even more of a stink, and
if for any reason it fails, there's a lot of units out there that I
can't get at to fix. I think we'll just have to accept that we're
going to have two master disks and sticker the units or something to
make it easy to tell the difference.
 
Back
Top