[LinuxBIOS] GA-M57SLI-S4 bios programming

[ST]

Hi

I am still puzzled how the second flash chip is to be used on the GA-M57SLI-S4 
board. As Peter mentioned LPC is used on this board. Would it be enough to 
use the flash chips (for programming and reading) to just disable one chip 
with the #init signal? It seems as if only one of the chips gets the #init to 
low, the other one will stay in reset mode and will keep its I/O pins in Z 
state?

Thanks
ST

[Peter Stuge]

On Thu, Apr 12, 2007 at 06:09:59PM +0200, ST wrote:
> I am still puzzled how the second flash chip is to be used on the
> GA-M57SLI-S4 board.

Without further investigation of the board, noone but Gigabyte can
say how it's supposed to be used.
> As Peter mentioned LPC is used on this board. Would it be enough to
> use the flash chips (for programming and reading) to just disable
> one chip with the #init signal?

Yes, sure.
> It seems as if only one of the chips gets the #init to low, the
> other one will stay in reset mode and will keep its I/O pins in Z
> state?

Yes, but the question is what, if anything, controls the second
INIT#. The patent suggests a timer circuit, but your measurements
show that perhaps the timer circuit is just not there on production
boards.

One solution is of course to not connect the two INIT# to the pads on
the board, but to a separate switch circuit.

Desoldering a single PLCC pin is not impossible with a little care.

//Peter

[ST]

Hi

Thanks for your answer Peter.
> > As Peter mentioned LPC is used on this board. Would it be enough to
> > use the flash chips (for programming and reading) to just disable
> > one chip with the #init signal?
>
> Yes, sure.

Ok, this is good news.
> > It seems as if only one of the chips gets the #init to low, the
> > other one will stay in reset mode and will keep its I/O pins in Z
> > state?
>
> Yes, but the question is what, if anything, controls the second
> INIT#. The patent suggests a timer circuit, but your measurements
> show that perhaps the timer circuit is just not there on production
> boards.

I think that there may be a watchdog placed at the open DIL pins nearby the 
flash if DualBios where to be used. But since there is plenty of
> One solution is of course to not connect the two INIT# to the pads on
> the board, but to a separate switch circuit.

I think that #init pin is connected to open pads for both flash chips. So it 
should be pretty easy (1 or 2 pullup/pulldown resistors and 1 switch/jumper).
Which would be much easier than desoldering a PLCC32 flash chip. The only 
thing i am not sure about is how the pulldown of #init on the soldered flash 
is realized.

I am currently waiting for Beth/Jose to double check and for the delivery of 
two spare flash chips and a PLCC32 socket.

ST

[Beth]

Hi all, some news ;)

I am still testing the pins but I have near the half tested, and I
have some interesting news, I must go to lunch and work and maybe
until tomorrow I couldnt finish the test task.

Well ST, pin 28 is connected to GND this was one marked as error, as I
go counting down this is the first "error" that I found.

The intersting part: pin 24 OE#, INIT# connected to, on the first
socket to T2,2 and seems to be tied to 5v using a resistor and a diode
(continuity only in one way, and my measurements are about 100K
resistor, maybe I am wrong), and pin 24 on the second socket to T12,
and seems to be un-connected (I must to do a more in depth search
maybe).

http://private.vlsi.informatik.tu-darmstadt.de/st/dual_bios_GA-m57SLI-S4.jpg

So, I think that we can cut the path from vcc to T22, and make a
switch that ties one of the two INIT# to vcc (using a resistor and a
diode), and the other to GND to ensure that the unselected one remains
on reset state.

What do you think about this?

Weel guys is time to lunch, see you later, regardss.

On 4/13/07, ST  wrote:
> Hi
>
> Thanks for your answer Peter.
> > > As Peter mentioned LPC is used on this board. Would it be enough to
> > > use the flash chips (for programming and reading) to just disable
> > > one chip with the #init signal?
> >
> > Yes, sure.
>
> Ok, this is good news.
> > > It seems as if only one of the chips gets the #init to low, the
> > > other one will stay in reset mode and will keep its I/O pins in Z
> > > state?
> >
> > Yes, but the question is what, if anything, controls the second
> > INIT#. The patent suggests a timer circuit, but your measurements
> > show that perhaps the timer circuit is just not there on production
> > boards.
>
> I think that there may be a watchdog placed at the open DIL pins nearby the
> flash if DualBios where to be used. But since there is plenty of
> > One solution is of course to not connect the two INIT# to the pads on
> > the board, but to a separate switch circuit.
>
> I think that #init pin is connected to open pads for both flash chips. So it
> should be pretty easy (1 or 2 pullup/pulldown resistors and 1 switch/jumper).
> Which would be much easier than desoldering a PLCC32 flash chip. The only
> thing i am not sure about is how the pulldown of #init on the soldered flash
> is realized.
>
> I am currently waiting for Beth/Jose to double check and for the delivery of
> two spare flash chips and a PLCC32 socket.
>
> ST