Problems with dual Tualatins .... BIOS or?

Only for programmers and BIOS gurus with technical questions.
Post Reply
New visitors - please read the rules.
Posts: 1
Joined: Sun Jan 05, 2003 7:31 pm

Hi fellas ... nice place you've got here.

I own a Tyan Thunder i840 (S2520) mainboard and have been working to get *dual* tualatin function with it. The board works just fine with a single Tualatin installed.

An issue arises when the second Tualatin is installed that I believe is BIOS related .... but I'm not 100% sure. ( AMI )

A bit of backround would be in order here ... I'll be brief.

I used to own a SM P3DR3 ( that's a slot1 i840 ) that a fella in Japan was able to get a pair of Tualatins working in ( his board , not mine ). He had modified a pair of MSI slockets ( the only brand he was able to get to function with the SM DRx board ) and made a couple of changes to his BIOS via AMIMM. adding the microcode and a small register change in the post.bin file of the AMI BIOS for that board.

I was able to extract and make similar changes to my SM board BIOS but lacked the ability to find a pair of MSI slockets of the proper revision. I abandoned the SM in favor of the Tyan i840 when I had an opportunity to get one.

The Tyan BIOS has the Tualatin microcode in place *and* the post.bin register change, I spoke of above, already. I thought this would be a lock.

On to the problem:
The Tyan POSTs and BOOTs W2K with both Tualatins installed and sees both processors. I'm using an UpgradeWare s370 adapter to remap the sockets. The system can be stressed with benchmarking for about 40-45 minutes then it will slowly come to a crawl and eventually freeze.

I have tried the OS install with either the MPS hal/kernel and the ACPI hal/kernel ... both exhibit the same results. During the OS install the system will most always lock when "Installing Devices" ( W2K set-up ). I finally got around this headache by using a 1gig coppermine and doing the install. Afterward I installed the Tualatin(s). This worked just fine. Even a bare, unpatched, minimal driver OS install displays the same result. It does however stay *up* longer under this "fresh", virgin condition.

I personally do not know enough about assembly code to know *what* it is I'm looking at in the extracted .bin files ... or where a desired change could/should be made.

Does this even sound like a BIOS issue?
The problem I have with suspecting the hardware is:
1) I have checked much of the important items ... cpu's and memory ... independently and they're good.
2) I believe the system would refuse to start or function *at all* with the Tualatin(s) installed.

Are there *any* resources available to help decipher all or part of the data registers ... or are these just part of OEM core files never to be seen by end users.

How do the independent BIOS assembly guys do it?
Post Reply