The firmware traps in SIS6xx/7xx/96x type chipsets

[r. ozgur doruk]

Hello,

I have Pentium4 laptop motherboard of which BIOS chip is soldered out by
some guys and it doesn't read newly programmed bios chip (a SST49lf080a) as
far as I understand since it even does not beep. And no harddisk signal, no
video and so on. In order to diagnose I have written a VHDL code (citing
Andy Green's Milksop experiment) and then program my code on a Xilinx CPLD
and connect it to the LPC debug board connector on the motherboard which has
the signals LAD0 - 3, LRST, LFRAME, LCLK. The job of my VHDL code is to
convert the LPC protocol to a parallel address and data combination so that
I can at least trace what the motherboard responds. When I do that, if I
give a long sync to the motherboard after the first address is received by
the PLD I understand that the motherboard starts to fetch the flash codes
from the adress 0xFFFFFFD0. In fact this conforms to the script written by
the current coreboot developer as the SIS 966 has a firmware trap in the
memory region starting from 0xFFFFFFD0. When I operate the system giving a
ready sync after each address reception to the PLD the system runs until
showing 0xFFFFFFDF and the value stays in the CPLD address output busses.
The same thing is observed when the board is operated without the CPU in its
socket.

I operate the mainboard without the CPU using a small hack connecting one of
the VID pins to the ground, thermal diode output to the vcc core, sckocc to
the ground and thermtrip to the vcc core. By that board thinks that CPU is
connected.

The interesting thing is that, when I measure the powergood and the reset
inputs to the processor (by plugging the wires to the wholes as no processor
is there). After the PLD address output is 0xFFFFFFDF both RESET and
POWERGOOD inputs become active so I think that the southbridge/northbridge
mechanism is alive. I also measured all of the processor socket holes one by
one and found no problematic conditions on the socket contacts.

The processor is heating up when operated without the heat sink and I also
noticed that thermtrip mechanism is also working as it shutdown after a high
value of temperature. Because of that I think that the processor is
defective but again I can not be sure about that because of this firmware
trap feature of the chipsets I mention. So are those firmware traps in the
SIS chipsets are effective on the boot process of the processor? Or any
other reasons?

Can I hear about your ideas?

Thanks for all considerations

Ozgur

[Joseph Smith]

On Tue, 6 Jul 2010 16:50:21 +0300, "r. ozgur doruk"
<[e-mail]> wrote:
> Hello,
>
> I have Pentium4 laptop motherboard of which BIOS chip is soldered out by
> some guys and it doesn't read newly programmed bios chip (a SST49lf080a)
> as
> far as I understand since it even does not beep. And no harddisk signal,
> no
> video and so on. In order to diagnose I have written a VHDL code (citing
> Andy Green's Milksop experiment) and then program my code on a Xilinx
> CPLD
> and connect it to the LPC debug board connector on the motherboard which
> has
> the signals LAD0 - 3, LRST, LFRAME, LCLK. The job of my VHDL code is to
> convert the LPC protocol to a parallel address and data combination so
> that
> I can at least trace what the motherboard responds. When I do that, if I
> give a long sync to the motherboard after the first address is received
> by
> the PLD I understand that the motherboard starts to fetch the flash codes
> from the adress 0xFFFFFFD0. In fact this conforms to the script written
> by
> the current coreboot developer as the SIS 966 has a firmware trap in the
> memory region starting from 0xFFFFFFD0. When I operate the system giving
> a
> ready sync after each address reception to the PLD the system runs until
> showing 0xFFFFFFDF and the value stays in the CPLD address output busses.
> The same thing is observed when the board is operated without the CPU in
> its
> socket.
>
> I operate the mainboard without the CPU using a small hack connecting one
> of
> the VID pins to the ground, thermal diode output to the vcc core, sckocc
> to
> the ground and thermtrip to the vcc core. By that board thinks that CPU
> is
> connected.
>
> The interesting thing is that, when I measure the powergood and the reset
> inputs to the processor (by plugging the wires to the wholes as no
> processor
> is there). After the PLD address output is 0xFFFFFFDF both RESET and
> POWERGOOD inputs become active so I think that the
> southbridge/northbridge
> mechanism is alive. I also measured all of the processor socket holes one
> by
> one and found no problematic conditions on the socket contacts.
>
> The processor is heating up when operated without the heat sink and I
> also
> noticed that thermtrip mechanism is also working as it shutdown after a
> high
> value of temperature. Because of that I think that the processor is
> defective but again I can not be sure about that because of this firmware
> trap feature of the chipsets I mention. So are those firmware traps in
> the
> SIS chipsets are effective on the boot process of the processor? Or any
> other reasons?
>
> Can I hear about your ideas?
>
> Thanks for all considerations

Very cool idea. 
I think SerialICE debugging may be alot easier, give you better results,
and alot more information.

http://www.serialice.com

-- 
Thanks,
Joseph Smith
Set-Top-Linux
www.settoplinux.org

[Rudolf Marek]

Hi,
> I can not be sure about that because of
> this firmware trap feature of the chipsets I mention. So are those
> firmware traps in the SIS chipsets are effective on the boot process of
> the processor? Or any other reasons?

I think they are independent of CPU itself. It usually configures some registers 
in chipsets for default values, like SB-NB bus.

If you cannot see any fetches except those, the CPU is not running or is unable 
to talk to the flash (defective route).

The thermtrip is sw independent so does not play role here.

Thanks
Rudolf