Re: [LinuxBIOS] different versions of the GA-M57SLI-S4 (PLCC vs SPI)
On 23.09.2007 23:16, echelon@free.fr wrote:
Quoting Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>:
OK, I have the 0.2 and 0.3 datasheet of IT8716F and I can't find any difference in interfaces between the datasheets. Please be more specific what you think has been replaced (including page numbers). Simply the pinout.. (please compare the pin-out diagram btw the 2 version of the DS).
I did. Pages 7-23 (Pin configuration) are exactly the same for 0.2 and 0.3. Please tell me the page number where you see any differences.
In fact, there could be another explanation : I talked about this issue with a hardware specialist at my work (he has worked into the IC design..) and his hypothesis is that the component which is actually used on this motherboard is a "custom" revision especially crafted by ITE for Gigabyte.. (yes, they had "volume" so they could afford to make a deal for a custom revision..)
Maybe. I still want to find out why your data sheet seems to differ from mine. Regards, Carl-Daniel
Carl-Daniel, I didn't say our datasheetd differ.. What I have said is that I did physical measurements on my motherboard and what I have measured didn't match at all the pin-out into the datasheet!! (see my previous posts..) Maybe this is only a minor hardware issue and it doesn't impact the software at all, but I prefered to signal it as an odd thing!.. Maybe someone with a v2.0 revision of m57sli could confirm my statements.. Quoting Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>:
On 23.09.2007 23:16, echelon@free.fr wrote:
Quoting Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>:
OK, I have the 0.2 and 0.3 datasheet of IT8716F and I can't find any difference in interfaces between the datasheets. Please be more specific what you think has been replaced (including page numbers). Simply the pinout.. (please compare the pin-out diagram btw the 2 version of the DS).
I did. Pages 7-23 (Pin configuration) are exactly the same for 0.2 and 0.3. Please tell me the page number where you see any differences.
In fact, there could be another explanation : I talked about this issue with a hardware specialist at my work (he has worked into the IC design..) and his hypothesis is that the component which is actually used on this motherboard is a "custom" revision especially crafted by ITE for Gigabyte.. (yes, they had "volume" so they could afford to make a deal for a custom revision..)
Maybe. I still want to find out why your data sheet seems to differ from mine.
Regards, Carl-Daniel
Hi Florentin, On 24.09.2007 17:12, echelon@free.fr wrote:
Carl-Daniel, I didn't say our datasheetd differ.. What I have said is that I did physical measurements on my motherboard and what I have measured didn't match at all the pin-out into the datasheet!! (see my previous posts..)
I'm sorry, I misunderstood.
Maybe this is only a minor hardware issue and it doesn't impact the software at all, but I prefered to signal it as an odd thing!..
Thanks for the signal.
Maybe someone with a v2.0 revision of m57sli could confirm my statements..
Unfortunately, I don't have a m57sli at all. Regards, Carl-Daniel
Quoting Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>:
On 23.09.2007 23:16, echelon@free.fr wrote:
Quoting Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net>:
OK, I have the 0.2 and 0.3 datasheet of IT8716F and I can't find any difference in interfaces between the datasheets. Please be more specific what you think has been replaced (including page numbers). Simply the pinout.. (please compare the pin-out diagram btw the 2 version of the DS). I did. Pages 7-23 (Pin configuration) are exactly the same for 0.2 and 0.3. Please tell me the page number where you see any differences.
In fact, there could be another explanation : I talked about this issue with a hardware specialist at my work (he has worked into the IC design..) and his hypothesis is that the component which is actually used on this motherboard is a "custom" revision especially crafted by ITE for Gigabyte.. (yes, they had "volume" so they could afford to make a deal for a custom revision..) Maybe. I still want to find out why your data sheet seems to differ from mine.
echelon@free.fr wrote:
Carl-Daniel, I didn't say our datasheetd differ.. What I have said is that I did physical measurements on my motherboard and what I have measured didn't match at all the pin-out into the datasheet!! (see my previous posts..) Maybe this is only a minor hardware issue and it doesn't impact the software at all, but I prefered to signal it as an odd thing!.. Maybe someone with a v2.0 revision of m57sli could confirm my statements..
Wow. I'm glad I found this thread. It helped me keep my sanity. My M57SLI-S4 V2.0 board(s) arrived Friday and I spent most of today studying the laout of the I want to install LinuxBIOS on. I was hoping to figure out how to enable the 2nd SPI chip that they have pads for. I've verified what Florentin sees is true. The physical pinout of the IT8716F on the board does NOT match the public datasheet. I've also made a discovery. The die inside the part is rotated. So the relative pinout _is_ the same only shifted. Take the pinout of the datasheet and do a +31 on the pin numbers wrapping at pins that are > 128. So Pin 1 of the datasheet is actually pin 32 on the board. Then it all lines up nicely. The key was the floppy signals. I noticed that the relative order matched the datasheet but only in the wrong location. So then I started checking pins next to the floppy signals and it all began to make sense. But I still don't yet know how to make the 2nd SPI part go using the signals routed on the board. CS# from the IT8716F is routed up to R509 which is a zero ohm resistor. If this resistor is in place then CS is hardwired to CS# on U5 which is the SPI chip that's loaded. If you pull R509 then the CS# to both chips are free to be selected by (unloaded) Q2,Q43,Q4, and Q5 + resistors but I don't have the configuration mapped out. It does not look like there is any easy way to re-enable switching between the SPI chips since you have to load several missing parts. I'll probably just end up soldering on a 2nd chip and then wiring the CS# pins up to a switch like the other mods did. -- Richard A. Smith smithbone@gmail.com
On Sat, Dec 01, 2007 at 07:46:14PM -0500, Richard Smith wrote:
CS# from the IT8716F is routed up to R509 which is a zero ohm resistor. If this resistor is in place then CS is hardwired to CS# on U5 which is the SPI chip that's loaded. If you pull R509 then the CS# to both chips are free to be selected by (unloaded) Q2,Q43,Q4, and Q5 + resistors but I don't have the configuration mapped out.
They would be part of Gigabyte's patented hardware BIOS failover technology I suppose. Q4-3 and Q5-3 are both connected to the superio side of R509, so the emitter if using PNP transistors. Traces from Q4-1 and Q5-1 both run toward the flash chips so they would be the collector. Q4-2 and Q5-2 the base, with R91 before Q4 and R90 before Q5. The other side of R91 goes to R389 which then goes to Q43-2. The other side of R90 goes to R86 which then goes to Q2-2. There are some vias on the traces between R{90,91} and Q{4,5} so they are connected to something else as well. (But what?) There are also vias on traces between R{86,389} and Q{2,43}. Q43 and Q4 are driven at the same time, through R389 and R91 respectively. I wonder what the purpose of Q43 and Q2 is. The pinout does indeed match e.g. a BC847 PNP transistor in SOT23 package. R89 is between Q4-1 (U5-CS#?) and a power net, so would be the pull-up for when Q4 is not driven to select U5. There is certainly a corresponding resistor for Q5-1 but there's only a via from the Q5-1 trace so it would have to be tested. My guess is R130 (directly south of R129) since it's other end goes to U9-CS#.
It does not look like there is any easy way to re-enable switching between the SPI chips since you have to load several missing parts.
The switch mod can be simplified to use existing pads and no pins have to be lifted from the flash chips anymore. 1. Remove R509. 2. Populate R89 and R130 with 10k or 100k pull-up 0402 resistors. 3. Solder the switch common to Q4-3 and switch between Q4-1 and Q5-1. Of course this assumes that soldering 0402 resistors is considered simple, which isn't likely true unless you're good at SMT soldering.
I'll probably just end up soldering on a 2nd chip and then wiring the CS# pins up to a switch like the other mods did.
Of course there could be some timer thingy to do failover, but I think manual control is best. I think the spring-loaded switch is as useful as any mechanism in this case. //Peter
Am Sonntag, 2. Dezember 2007 05:48:23 schrieb Peter Stuge:
On Sat, Dec 01, 2007 at 07:46:14PM -0500, Richard Smith wrote:
CS# from the IT8716F is routed up to R509 which is a zero ohm resistor. If this resistor is in place then CS is hardwired to CS# on U5 which is the SPI chip that's loaded. If you pull R509 then the CS# to both chips are free to be selected by (unloaded) Q2,Q43,Q4, and Q5 + resistors but I don't have the configuration mapped out.
They would be part of Gigabyte's patented hardware BIOS failover technology I suppose.
Q4-3 and Q5-3 are both connected to the superio side of R509, so the emitter if using PNP transistors.
Traces from Q4-1 and Q5-1 both run toward the flash chips so they would be the collector.
Q4-2 and Q5-2 the base, with R91 before Q4 and R90 before Q5. The other side of R91 goes to R389 which then goes to Q43-2. The other side of R90 goes to R86 which then goes to Q2-2. There are some vias on the traces between R{90,91} and Q{4,5} so they are connected to something else as well. (But what?) There are also vias on traces between R{86,389} and Q{2,43}.
Q43 and Q4 are driven at the same time, through R389 and R91 respectively. I wonder what the purpose of Q43 and Q2 is.
The pinout does indeed match e.g. a BC847 PNP transistor in SOT23 package.
R89 is between Q4-1 (U5-CS#?) and a power net, so would be the pull-up for when Q4 is not driven to select U5.
There is certainly a corresponding resistor for Q5-1 but there's only a via from the Q5-1 trace so it would have to be tested. My guess is R130 (directly south of R129) since it's other end goes to U9-CS#.
It does not look like there is any easy way to re-enable switching between the SPI chips since you have to load several missing parts.
The switch mod can be simplified to use existing pads and no pins have to be lifted from the flash chips anymore.
1. Remove R509. 2. Populate R89 and R130 with 10k or 100k pull-up 0402 resistors. 3. Solder the switch common to Q4-3 and switch between Q4-1 and Q5-1. Confirmed. But not with SMD Resistors.
First I removed the R509. As there are connections from R89 Left to U5 VCC; from R89 Right to U9 CS#; from R130 Left to U5 CS# and from R130 Right to U9 VCC I soldered normal 100k resistors between U5 VCC and U9 CS# and between U5 CS# and U9 VCC. Here are two photos of my new mod: http://img141.imageshack.us/img141/8866/dscf1791ob2.jpg http://img104.imageshack.us/img104/2579/dscf1792nn2.jpg I know, that these cables to the sockel are not really fine, but i had no other solution for mounting the sockel on the mainboard and it works fine! I added a sockel for the SPI-chips to be able to change the bios chip in an easy way. If someone is interested which sockels these are, they are manufactured by WELLS-CTI and have the part number 652C0082211-W003. I payed about 8€ per part, and that sould be about 10$, without shipping costs. The distributer for these sockels was http://www.bfioptilas.com/. (PS: thanks to Mr. A. v. Heydwolff for organising these sockels.)
Of course this assumes that soldering 0402 resistors is considered simple, which isn't likely true unless you're good at SMT soldering. A friend of mine helped me with the soldering, but he said that it is nearly impossible to solder these resistors without industry-equipment.
I'll probably just end up soldering on a 2nd chip and then wiring the CS# pins up to a switch like the other mods did.
Of course there could be some timer thingy to do failover, but I think manual control is best. I think the spring-loaded switch is as useful as any mechanism in this case.
//Peter
On Thu, Jan 10, 2008 at 12:31:31AM +0100, Harald Gutmann wrote:
Of course this assumes that soldering 0402 resistors is considered simple, which isn't likely true unless you're good at SMT soldering. A friend of mine helped me with the soldering, but he said that it is nearly impossible to solder these resistors without industry-equipment.
Actually, if you're interested in SMT soldering, check out this '101' video: http://www.curiousinventor.com/guides/Surface_Mount_Soldering/101 There is some very helpful information in there! Thanks, Ward. -- Ward Vandewege <ward@fsf.org> Free Software Foundation - Senior System Administrator
On Thu, Jan 10, 2008 at 10:04:43AM -0500, Ward Vandewege wrote:
Actually, if you're interested in SMT soldering, check out this '101' video:
http://www.curiousinventor.com/guides/Surface_Mount_Soldering/101
There is some very helpful information in there!
Indeed! I definately recommend this even if you actually don't own a soldering iron yet, but have thought about buying one, and certainly if you already own one. :) //Peter
On Thu, Jan 10, 2008 at 12:31:31AM +0100, Harald Gutmann wrote:
The switch mod can be simplified to use existing pads and no pins have to be lifted from the flash chips anymore.
1. Remove R509. 2. Populate R89 and R130 with 10k or 100k pull-up 0402 resistors. 3. Solder the switch common to Q4-3 and switch between Q4-1 and Q5-1.
Confirmed. But not with SMD Resistors.
Great, thanks for the confirmation!
First I removed the R509. As there are connections from R89 Left to U5 VCC; from R89 Right to U9 CS#; from R130 Left to U5 CS# and from R130 Right to U9 VCC I soldered normal 100k resistors between U5 VCC and U9 CS# and between U5 CS# and U9 VCC.
Here are two photos of my new mod: http://img141.imageshack.us/img141/8866/dscf1791ob2.jpg http://img104.imageshack.us/img104/2579/dscf1792nn2.jpg
Looks good!
I know, that these cables to the sockel are not really fine, but i had no other solution for mounting the sockel on the mainboard and it works fine!
As long as it works, it is good enough. :) //Peter
Great work Richard! In fact what you have found, confirms the theory of one of my cow-workers that sometimes MB manufacturers ask chip makers to issue "custom" revisions for some types of components used in new series of a MB. (Of course the specs of these revisions remain strictly confidential naturally.. why they do this one can simply wonder.. after all business is business so what?!..) Btw what are the issues that remain unsolved on this board? (I know, I know, I have to check the wiki..). What is the priority for this board? Florentin Quoting Richard Smith <smithbone@gmail.com>:
echelon@free.fr wrote:
Carl-Daniel, I didn't say our datasheetd differ.. What I have said is that I did physical measurements on my motherboard and what I have measured didn't match at all the pin-out into the datasheet!! (see my previous posts..) Maybe this is only a minor hardware issue and it doesn't impact the software at all, but I prefered to signal it as an odd thing!.. Maybe someone with a v2.0 revision of m57sli could confirm my statements..
Wow. I'm glad I found this thread. It helped me keep my sanity.
My M57SLI-S4 V2.0 board(s) arrived Friday and I spent most of today studying the laout of the I want to install LinuxBIOS on. I was hoping to figure out how to enable the 2nd SPI chip that they have pads for.
I've verified what Florentin sees is true. The physical pinout of the IT8716F on the board does NOT match the public datasheet. I've also made a discovery. The die inside the part is rotated. So the relative pinout _is_ the same only shifted.
Take the pinout of the datasheet and do a +31 on the pin numbers wrapping at pins that are > 128. So Pin 1 of the datasheet is actually pin 32 on the board. Then it all lines up nicely.
The key was the floppy signals. I noticed that the relative order matched the datasheet but only in the wrong location. So then I started checking pins next to the floppy signals and it all began to make sense.
But I still don't yet know how to make the 2nd SPI part go using the signals routed on the board.
CS# from the IT8716F is routed up to R509 which is a zero ohm resistor. If this resistor is in place then CS is hardwired to CS# on U5 which is the SPI chip that's loaded. If you pull R509 then the CS# to both chips are free to be selected by (unloaded) Q2,Q43,Q4, and Q5 + resistors but I don't have the configuration mapped out.
It does not look like there is any easy way to re-enable switching between the SPI chips since you have to load several missing parts.
I'll probably just end up soldering on a 2nd chip and then wiring the CS# pins up to a switch like the other mods did.
-- Richard A. Smith smithbone@gmail.com
Am Sonntag, 2. Dezember 2007 16:08:12 schrieb echelon@free.fr:
Great work Richard! In fact what you have found, confirms the theory of one of my cow-workers that sometimes MB manufacturers ask chip makers to issue "custom" revisions for some types of components used in new series of a MB. (Of course the specs of these revisions remain strictly confidential naturally.. why they do this one can simply wonder.. after all business is business so what?!..) Btw what are the issues that remain unsolved on this board? (I know, I know, I have to check the wiki..). What is the priority for this board? Florentin
one of the main big things on that board is the missing ACPI implementation. the other issues seem to be just little things: flashrom isn't working when lb is booted. you need "NoDDC2" in your xorg.conf, else the startup of the x-server is really slow. regards, harald
Hi
one of the main big things on that board is the missing ACPI implementation. the other issues seem to be just little things: ACPI or in my case fan control is a real showstopper for me. What has to be done to remedie this problem? flashrom isn't working when lb is booted. Only on the newer boards i suppose?
ST
Am Mittwoch, 5. Dezember 2007 13:44:53 schrieb ST:
Hi
one of the main big things on that board is the missing ACPI implementation. the other issues seem to be just little things:
ACPI or in my case fan control is a real showstopper for me. What has to be done to remedie this problem? fancontrol and cool'n'quite and the powerdown is missing without acpi. i think there is just no acpi code in the lb part for the m57sli4
flashrom isn't working when lb is booted. Only on the newer boards i suppose? only on the spi version of the board. (rev 2.0)
ST
Hi all, Adding ACPI support which should at least do poweroff properly or deliver power button event is quite simple. Maybe I can write some howto to wiki? Rudolf
On Wed, Dec 05, 2007 at 02:07:38PM +0100, Rudolf Marek wrote:
Hi all, Adding ACPI support which should at least do poweroff properly or deliver power button event is quite simple. Maybe I can write some howto to wiki?
Please do. //Peter
On Wed, Dec 05, 2007 at 02:07:38PM +0100, Rudolf Marek wrote:
Hi all, Adding ACPI support which should at least do poweroff properly or deliver power button event is quite simple. Maybe I can write some howto to wiki?
Yes, please! Thanks, Ward. -- Ward Vandewege <ward@fsf.org> Free Software Foundation - Senior System Administrator
On 05.12.2007 14:00, Harald Gutmann wrote:
Am Mittwoch, 5. Dezember 2007 13:44:53 schrieb ST:
Hi
one of the main big things on that board is the missing ACPI implementation. the other issues seem to be just little things:
ACPI or in my case fan control is a real showstopper for me. What has to be done to remedie this problem?
fancontrol and cool'n'quite and the powerdown is missing without acpi. i think there is just no acpi code in the lb part for the m57sli4
flashrom isn't working when lb is booted.
Only on the newer boards i suppose?
only on the spi version of the board. (rev 2.0)
Can someone with a logic probe or oscilloscope debug that? Once I know what's wrong with the signals, I can fix the code. Regards, Carl-Daniel
Carl-Daniel Hailfinger wrote:
fancontrol and cool'n'quite and the powerdown is missing without acpi. i think there is just no acpi code in the lb part for the m57sli4
flashrom isn't working when lb is booted.
Only on the newer boards i suppose?
only on the spi version of the board. (rev 2.0)
Can someone with a logic probe or oscilloscope debug that? Once I know what's wrong with the signals, I can fix the code.
I'll be happy to. So to verify: I need to boot LB (what svn rev?) on M557SLI-S4 rev 2.0 and then figure out what signal is not working correctly when you try to reflash with flashrom. -- Richard A. Smith smithbone@gmail.com
On 07.12.2007 20:28, Richard Smith wrote:
Carl-Daniel Hailfinger wrote:
fancontrol and cool'n'quite and the powerdown is missing without acpi. i think there is just no acpi code in the lb part for the m57sli4
flashrom isn't working when lb is booted.
Only on the newer boards i suppose?
only on the spi version of the board. (rev 2.0)
Can someone with a logic probe or oscilloscope debug that? Once I know what's wrong with the signals, I can fix the code.
I'll be happy to.
So to verify:
I need to boot LB (what svn rev?) on M557SLI-S4 rev 2.0 and then figure out what signal is not working correctly when you try to reflash with flashrom.
Current svn revision, please. The rest exactly like you described. IIRC Florentin wanted to trace this as well. Maybe you can coordinate? I have no idea whether I have internet access tomorrow. The patch below may help to force writes to the chip. Maybe you need to comment out the other busy wait loops as well and replace them with usleep(1000) or something like that. Index: spi.c =================================================================== --- util/flashrom/spi.c (Revision 2998) +++ util/flashrom/spi.c (Arbeitskopie) @@ -163,9 +163,9 @@ uint8_t busy, writeenc; int i; - do { + /*do { busy = inb(port) & 0x80; - } while (busy); + } while (busy); */ if (readcnt > 3) { printf("%s called with unsupported readcnt %i.\n", __FUNCTION__, readcnt); Regards, Carl-Daniel
On Wed, Dec 05, 2007 at 11:50:35AM +0100, Harald Gutmann wrote:
Am Sonntag, 2. Dezember 2007 16:08:12 schrieb echelon@free.fr:
Great work Richard! In fact what you have found, confirms the theory of one of my cow-workers that sometimes MB manufacturers ask chip makers to issue "custom" revisions for some types of components used in new series of a MB. (Of course the specs of these revisions remain strictly confidential naturally.. why they do this one can simply wonder.. after all business is business so what?!..) Btw what are the issues that remain unsolved on this board? (I know, I know, I have to check the wiki..). What is the priority for this board? Florentin
one of the main big things on that board is the missing ACPI implementation.
Yeah. Because of this, no soft power off, etc.
the other issues seem to be just little things: flashrom isn't working when lb is booted.
It does for me on my v1.1 board.
you need "NoDDC2" in your xorg.conf, else the startup of the x-server is really slow.
Yeah. I'm still not sure why this is. Thanks, Ward. -- Ward Vandewege <ward@fsf.org> Free Software Foundation - Senior System Administrator
participants (8)
-
Carl-Daniel Hailfinger -
echelon＠free.fr -
Harald Gutmann -
Peter Stuge -
Richard Smith -
Rudolf Marek -
ST -
Ward Vandewege