NSC TPM Error

[N1K]

We are cloning PC-s in our company, since we have more than 1000 users..

Everything worked fine untill we ordered new IBM Thinkcentre PC-s with 3,2 GHz

The OS is Windows XP with SP1 and all of the security patches...(haven't tested SP2

Now, during the windows update we have the option to update National Semi Conductor TPM device, and if we update the computer freezes.

Has anyone this problem?

[tes1966]

Yes are seeing that same problem. We have S51 here that are having the issue. We can setup an unattended installation of the OS and have Windows setup install the driver with no issues. But, if we take a sysprep'd image and try have minisetup do the install or do a manual install of the driver after minisetup the system freezes.

Have you been able to find a fix for you problem?

[semion]

hi, i have the same problem with ibm thincentre machines. any solution for sysprep'ed installation of the tpm device driver? Thanks.

Semion

[N1K]

Unfortunatelly we didn't solve this problem. That device is something that IBM is starting to implement in their new PC-s.

We've just disabled this device. If you make a clean install of Windows and then tried to update this device, everything is working normally..

[tes1966]

Hey There... I got this working a couple of weeks ago. Here is what I did.

Do an unattend setup of Windows XP on you donor machine.

Change the HAL (the device listed under Computer in the Device Manager) to "Advanced Configuration and Power Interface (ACPI)".

Setup your SYSPREP directory as usual but in addition create a subfolder called "HAL".

EXPAND from your i386 source the following files unto the "HAL" directory:

hal.dll

hal.inf

halaacpi.dll

halacpi.dll

halapic.dll

halmacpi.dll

halmps.dll

halsp.dll

Add the following line into your SYSPRE.INF file under the [unattended] section:

UpdateUPHAL = "ACPIAPIC_UP,%SystemDrive%\Sysprep\Hal\Hal.inf"

Make sure that the NSC TPM driver files are included on your donor machine but in a directory that will not be accesed by Windows XP during it normal PnP device detection. ie. not in the OemPnPDriversPath= in your SYSPREP.INF file.

Create a batch file that will copy the NSC TPM drivers into on of the directories that you have listed in the OemPnPDriversPath= in your SYSPREP.INF file. eg. OemPnPDriversPath=Drivers\TPM;.

Add a line in the SYSPREP.INF file under the [GuiRunOnce] section that will call this above created batch file. eg. "c:\temp\copytpm.bat"

Run SYSPREP

Clone the donor machine (Ghost, DriveImage, etc)

Try it on the S51

When the system first boots on the target machine SYSPREP will up the HAL to what is needed. Then SYSPREP will copy the driver over so Windows PnP can install it. Windows may say something like it's finished installing new hardware and needs to reboot. Reboot and you should be good to go.

The TCM chip in the S51 needs an "ACPI Uniprocessor PC" or "ACPI Multiprocessor PC" HAL on the machine. If you don't have this HAL the driver will lock the system up bacause it will access an IRQ that is not available to it and Windows being Windows it locks up.

Hope this help and works for you. We beat are heads on this for over a week and finally got this to work and it works great for us.

By the way, I work for IBM and we are using IBM's ThinkVantage tool called ImageUltra Builder to automate the above process.

[redhelix]

That's Great..... BUT how do you fix it without redoing the image from scratch the way you described?

BTW - I'm a huge IBM/Lenovo Customer.

Edited August 2, 2005 by redhelix

[tes1966]

Sorry but you don't. Windows XP has to have an "ACPI Uniprocessor PC" or "ACPI Multiprocessor PC" HAL. If you don't, the TPM driver will hang the machine and the only way to change it is to run SYSPREP.

[hasbrotech]

anyone figure out a fix the this issue.

Have just ran into it. Have a new IBM T43P and im using my XP image on it and when I go to update the Driver it lock up tight ? Any ideas ??

[dpjordan]

I've had a little experience with the Thinkpad T43 and the NSC TPM. I am trying to do the same thing the author of this thread is trying to do. The only solution I could find was to load our base GHOST image on the laptop, log in as ADMIN, set the resources that the "banged out" TPM device is using to IRQ11, anything other than 11 would lock the machine up when I installed the driver. This still doesn't solve the problem of the driver loading from sysprepped image, but it is a workaround.

[maxn]

hasbrotech,

I just addressed this issue at our company and found a good Microsoft site that explains it. Basically if you want to load the TPM driver AFTER sysprep you have to make sure the HAL on the PC that the image was built on matches the HAL on the PC that you're using the sysprepped image on. Search on MS article ID 309283 for detailed info. I did some testing on various HAL platforms and what they say is true if you want to load the TPM driver AFTER sysprep. Hope this helps!

[maxn]

dpjordan,

Thanks for your IRQ info - this works well with my deployed images that have the TPM.

[hasbrotech]

thanks for the fast responses all !!! I really appreciate it !!

Jared

[tes1966]

I'm wondering if anyone has tried the Sysprep solution that I outlined above? I would like to know if this works for anyone other than me. Maybe I didn't document it correctly?

This has nothing to do with Microsoft doc 309283. It has everything to do with IRQ's as I previously stated. If you don't have the correct HAL on the machine you will never be able to properly deploy an image on a machine that has this hardware. Also, this Microsoft doc is not entirely correct when it talks about what HAL can be depoyed on what type of machine. What they are doing is covering their a**. You can really screw things up by changing the HAL to something that the hardware doesn't like. Just like modifying the registry. Microsoft shows you how to do, gives you the tools to do it, but will not be held resonsable when you screw it up. The same goes here.

You either have to start with the correct HAL or change it to the correct HAL with Sysprep. Modifying the IRQ that the driver uses doesn't really help you create an image that works on all your target hardware.

If you want to create an image that can be deployed on 99% of Dells, HP's, IBM, white box, desktop, notebook's you need to start with an "Advanced Configuration and Power Interface (ACPI)" and then change it, when needed, to an uplevel HAL like the "ACPI Uniprocessor PC".

[kalleh2003]

Hi,

I was searching the web for a solution to the same problem too and the IRQ fix did not help us. However, on the new T43 devices we did get what helped in the end was to install the driver for the Atmel TPM PnP Device altough XP found the NSC device and wanted a driver for that (and froze the system)

Just thought I let you know here. You can get the driver here: IBM Atmel Driver

Regards,

KalleH2003

[tokyotower1717]

Hi Tes1966... re your post "NSC TPM Error" on 15th April I'm going to try the same thing out first thing I get into the office later. We're running a series of demo notebooks on Windows 2000 Servers in a Compaq Evo N610c machine (HAL is HALACPI.DLL) and we now need to migrate these images to an IBM T43 (HAL needed is HALAACPI.DLL). Everything that I've read from the Microsoft Sysprep stuff tells me that the two HALS are IMCOMPATIBLE which is leaving me very frustrated. Hope that your instructions work for me *fingers crossed*.

One thing though, why did you recommend the step of using copytpm.bat to copy the NSC TPM drivers separately? I'd like to get a better understanding...

Thanx so much!

Adrian

tokyotower1717@yahoo.com